From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-f180.google.com (mail-io0-f180.google.com [209.85.223.180]) by dpdk.org (Postfix) with ESMTP id 202EF1B352 for ; Tue, 26 Dec 2017 08:44:35 +0100 (CET) Received: by mail-io0-f180.google.com with SMTP id t196so31880601iof.0 for ; Mon, 25 Dec 2017 23:44:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=J9QENTVj4P9oR0A708Cj8kzoHb/nBh6p3I5Vqyw+0yc=; b=rf9it7PrSGf37/trCTIc0NFug4rEqIIwbNkJYdoTmVC2LFchPRrezwlhZBBhYGcLeU xzNg1YjLBy7CPZyjOhlXSKXoRNe25jbp/pbo6dS16amGb/D+c8GEU8z9bfT8DDf2Zxjs Kzi6NL6LVHwCGRA9Q34aTXgSZTcttm5uXI3uKX3CwVT6rtaalPClNbJ23Rx5Ka5LIBZX yo0eFftJO0TFVsglJZpKyOAjagZ+W4ja6Ixi99VoisZ38k8eW+l1bKB3hWDQFI0PvRQj j/3OkUfS+JK/6SgvFVThEZuOqvs7cRre7s1cpDpu4QJa6MBJyCw2b1JPdQcnl4spBppS 9YHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=J9QENTVj4P9oR0A708Cj8kzoHb/nBh6p3I5Vqyw+0yc=; b=FYtiZazzv4xy99P1mgNCK73QcKcJyDPZw4Ou0sriGayTr3N3UlHptiBnhfdfLwInYQ nMXFFgCLncHuGnUHXZgpdngAmYkITTqbx8Kfezg4uAKDqstLPX52OOYSVx87WDNf5oxV wS7LezdAz7JIBZDVZRPMbUtY6XBcId3dYdVxUZocOMhwad97revv3fWCu6yhj3HAqIsw XGEPhx3WpBmHldgRlacmn1/G37QXy9vBwD4zbefGe5LQAClvnE7gKRlayO2/DSJbN/YX 6YiCp0luhO3vrym7gq+qEdMSrWaDInY19EoCCBY5B83fYcxO5dw2Qas0GEiU4J5lQEnH ukfw== X-Gm-Message-State: AKGB3mJaz+2pnOyGAvG36d/URa/ssMzOvFSGc9+DDHIGebkOyu4GfYdP 7PfFl61qz+qe6QfJjb97JNGZkAqauQx5xRy6XvE1RWPE X-Google-Smtp-Source: ACJfBotxPYGiC3d3TJ6wfVIdc2CmR/uDCJ34G50e4ScEa0dWWDDv+H4p4ozNPUd/kejSlbZvaaX9qnTfZoyp5wq0CTA= X-Received: by 10.107.174.201 with SMTP id n70mr34097061ioo.45.1514274274192; Mon, 25 Dec 2017 23:44:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.53.2 with HTTP; Mon, 25 Dec 2017 23:44:33 -0800 (PST) In-Reply-To: <039ED4275CED7440929022BC67E7061153125026@SHSMSX103.ccr.corp.intel.com> References: <1513823719-36066-1-git-send-email-qi.z.zhang@intel.com> <1513823719-36066-4-git-send-email-qi.z.zhang@intel.com> <039ED4275CED7440929022BC67E7061153124111@SHSMSX103.ccr.corp.intel.com> <039ED4275CED7440929022BC67E7061153125026@SHSMSX103.ccr.corp.intel.com> From: Alex Rosenbaum Date: Tue, 26 Dec 2017 09:44:33 +0200 Message-ID: To: "Zhang, Qi Z" Cc: "adrien.mazarguil@6wind.com" , DPDK , "Doherty, Declan" , "Chandran, Sugesh" Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [RFC v2 3/5] ether: Add flow timeout support X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Dec 2017 07:44:35 -0000 On Tue, Dec 26, 2017 at 5:28 AM, Zhang, Qi Z wrote: >> On Fri, Dec 22, 2017 at 11:03 AM, Zhang, Qi Z wrote: >> >> On Thu, Dec 21, 2017 at 4:35 AM, Qi Zhang wrote: >> >> > Add new APIs to support flow timeout, application is able to 1. >> >> > Setup the time duration of a flow, the flow is expected to be >> >> > deleted automatically when timeout. >> >> >> >> Can you explain how the application (OVS) is expected to use this API? >> >> It will help to better understand the motivation here... >> > >> > I think the purpose of the APIs is to expose the hardware feature that >> > support flow auto delete with a timeout. >> > As I know, for OVS, every flow in flow table will have time duration A >> > flow be offloaded to hardware is still required to be deleted in >> > specific time, I think these APIs help OVS to take advantage HW >> > feature and simplify the flow aging management >> >> Are you sure this will allow OVS to 'fire-and-forget' about the rule removal? >> or will OVS anyway do rule cleanup from application tables? > > There is some framework design about offload flow management on OVS side. > Since I'm not a OVS guy, I can't answer OVS specific question precisely right now, > but the feedback I got is, it will be nice if rte_flow could support flow timeout > I may check with some OVS expert to give further explanation. > BTW, I think there is no harmful to add these APIs into rte_flow, since a flow timeout is quite > generic feature to me. it may be useful even for non-OVS case in future. I'm not a core OVS guy ether :) but adding a feature to DPDK because it "might be nice" and not a "real benefit" does not sound like a right approach to me. Each new feature will add extra work/support/bugs for something which might not really used. I think it is critical that OVS guys provide you a clear evidence how this will help. And we need to try and make this generic so other then OVS application can use this. e.g. adding a re-arm to the timeout. >> Do you know if OVS flow timers are (or can be) re-armed in different use >> cases? e.g. extending the timeout duration if traffic is still flowing? > > As I know, for OVS every flow just has a fixed time duration, so "hard_timeout" > is going for this requirement, but by following OpenFlow spec, idle_timeout is paired > with hard_timeout so I just add it since its generic and maybe useful for future. Yes, I also heard OF does issue a hard timeout value. But I also understood from OVS guys that OVS will manage the timeout internally. OVS will do traffic sampling for activity before deleting the flow. so that the timeout value needs to be updated constantly depending on connection state information (re you other patch exposing the last_seen_timeout). So the current suggestion, based on hard timeout, will not fit OVS. At least as I understood from other OVS guys. You can see that Kernel OVS guys did not add this to TC flower offload support ether. I am sure they would have if it would have improved performance. That will be a fame if we miss the target of the feature. >> >> Are you trying to move the aging timer from application code into the >> PMD? >> >> or can your HW remove/disable/inactivate a flow at certain time >> >> semantics without software context? >> > >> > Yes, it for hardware feature. >> >> So if the hardware auto removes the hardware steering entry, what software >> part deletes the rte_flow handle? >> What software part triggers the application callback? from what context? will >> locks be required? >> How do you prevent races between application thread and the context >> deleting/accessing the rte_flow handle? >> I mean in cases that application wants to delete the flow before the timeout >> expires, but actually it is same time hardware deletes it. > > Usually the flow auto delete is running on a separate background thread > (an interrupt handler or a watchdog thread base on hardware capability) > The low level driver is responsible to take care of the race condition between background and foreground flow deleting. Please explain in details how the race is solved. Maybe a patch will make this clearer? This is one of the main objection for this feature. e.g.: If the application holds a rte_flow handle, and the timeout expired, is not handled yet. Now the application will try to use the rte_flow which state changed underneath, or even got deleted. Besides you now require each and every low level driver to add this same timeout expiration logic, alarm registration and race protection. This should be done once for all PMD's. PS: Will this callback thread clear the HW rule as well? > For application, it should be aware Need to make this clear in API definitions > that the callback function is running on a separate thread, so it is also required to > take care of race condition if it will access some data that is shared by foreground thread. This means locks in application? or some lock-less async model? Isn't it simpler to let the application (OVS) delete the rte_flow from it's own thread, save locks, allow timeout updates according traffic counter. Alex