From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-f178.google.com (mail-qk0-f178.google.com [209.85.220.178]) by dpdk.org (Postfix) with ESMTP id 485F220F for ; Wed, 14 Dec 2016 14:54:33 +0100 (CET) Received: by mail-qk0-f178.google.com with SMTP id q130so20504340qke.1 for ; Wed, 14 Dec 2016 05:54:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=otqUcWCmx+/IRHMfWifl5EJH7AMT6YPM/whP0UrnkDU=; b=UlfiPvTNoXOE5oTNMyB1066WjEW2gKAsqQNPTN04wd9GUrWmqY3SU+k+rV9KlWeXsx BC78pE7cMjgbp3yETa7yydrikRNei3f79iQW8wGa6syV7rQqClhHTEcX2GnEECdjBW5Y zzb+WMXbhmoPHJeKcDGB0AHWT0jXIZE42aBLPGUUG7xrDp3t6c1PHqhDeZryXYRFW98L B7CDfbpK9HWUfBKKf9Jnk/o3MgsBzOoEZZ1xItEHQ/hRhvkLsOsFIWLO4537pXn/Kx9v CcFo30wpf8Ufp4uBlBy/UBqp0UAEThVQCraFcJYafTr0jey48tTX7Tni0nsS7baRhhws qPkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=otqUcWCmx+/IRHMfWifl5EJH7AMT6YPM/whP0UrnkDU=; b=rM2I9JAg9YjaF7PP6vu/eIOlyNaAi1cihVWhdrq0gS6VAgwF1YV47mlddZk3k1HEf8 StEG8ffGy+YRkfcHhKsFhy+8lfP6ZfeejElsDH5SI6sy77yUXZED+ZImaU4dS9eyGT3f j4T+s3q2jA0JOusaX/Rs3Q9Q0FdawABmdjwbAyCaUA/ede/7tGe74sckD70vMvYat4Ji PEc5eQM70x9WQfHAB791bjaSfjzngKiQh1UZ0rL654sippEN8pbeYqh6Lx0D0tdLCyRb hPylRYS3Sa9dQG0jDJuqQhRXuj6YEF2KdRTS4lZikBnuVQpMFDuODvgwIT2vtg6bGVnE onVg== X-Gm-Message-State: AKaTC00WAB2juBxguPXqmwBE5drdxfi5Gb8WA4UHFLLoyQchg+Sf6I9OM7seiUWhpm2rMPCA X-Received: by 10.28.173.4 with SMTP id w4mr6946801wme.70.1481723672465; Wed, 14 Dec 2016 05:54:32 -0800 (PST) Received: from 6wind.com (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by smtp.gmail.com with ESMTPSA id f76sm7756013wmd.15.2016.12.14.05.54.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Dec 2016 05:54:31 -0800 (PST) Date: Wed, 14 Dec 2016 14:54:23 +0100 From: Adrien Mazarguil To: Kevin Traynor Cc: dev@dpdk.org, Thomas Monjalon , Pablo de Lara , Olivier Matz , sugesh.chandran@intel.comn Message-ID: <20161214135423.GZ10340@6wind.com> References: <1c8a8e4fec73ed33836f1da9525b1b8b53048518.1479309720.git.adrien.mazarguil@6wind.com> <59393e58-6c85-d2e5-1aab-a721fe9c933e@redhat.com> <20161201083652.GI10340@6wind.com> <7f65ba09-e6fe-d97a-6ab5-97e84a828a81@redhat.com> <20161208170715.GM10340@6wind.com> <5c53f86b-ead7-b539-6250-40613c7a57db@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5c53f86b-ead7-b539-6250-40613c7a57db@redhat.com> Subject: Re: [dpdk-dev] [PATCH 01/22] ethdev: introduce generic flow API 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: Wed, 14 Dec 2016 13:54:33 -0000 Hi Kevin, On Wed, Dec 14, 2016 at 11:48:04AM +0000, Kevin Traynor wrote: > hi Adrien, sorry for the delay > > <...> > > >>>> > >>>> Is it expected that the application or pmd will provide locking between > >>>> these functions if required? I think it's going to have to be the app. > >>> > >>> Locking is indeed expected to be performed by applications. This API only > >>> documents places where locking would make sense if necessary and expected > >>> behavior. > >>> > >>> Like all control path APIs, this one assumes a single control thread. > >>> Applications must take the necessary precautions. > >> > >> If you look at OVS now it's quite possible that you have 2 rx queues > >> serviced by different threads, that would also install the flow rules in > >> the software flow caches - possibly that could extend to adding hardware > >> flows. There could also be another thread that is querying for stats. So > >> anything that can be done to minimise the locking would be helpful - > >> maybe query() could be atomic and not require any locking? > > > > I think we need basic functions with as few constraints as possible on PMDs > > first, this API being somewhat complex to implement on their side. That > > covers the common use case where applications have a single control thread > > or otherwise perform locking on their own. > > > > Once the basics are there for most PMDs, we may add new functions, items, > > properties and actions that provide additional constraints (timing, > > multi-threading and so on), which remain to be defined according to > > feedback. It is designed to be extended without causing ABI breakage. > > I think Sugesh and I are trying to foresee some of the issues that may > arise when integrating with something like OVS. OTOH it's > hard/impossible to say what will be needed exactly in the API right now > to make it suitable for OVS. > > So, I'm ok with the approach you are taking by exposing a basic API > but I think there should be an expectation that it may not be sufficient > for a project like OVS to integrate in and may take several > iterations/extensions - don't go anywhere! > > > > > As for query(), let's see how PMDs handle it first. A race between query() > > and create() on a given device is almost unavoidable without locking, same > > for queries that reset counters in a given flow rule. Basic parallel queries > > should not cause any harm otherwise, although this cannot be guaranteed yet. > > You still have a race if there is locking, except it is for the lock, > but it has the same effect. The downside of my suggestion is that all > the PMDs would need to guarantee they could gets stats atomically - I'm > not sure if they can or it's too restrictive. > > > > > <...> > > >> > >>> > >>>>> + > >>>>> +/** > >>>>> + * Destroy a flow rule on a given port. > >>>>> + * > >>>>> + * Failure to destroy a flow rule handle may occur when other flow rules > >>>>> + * depend on it, and destroying it would result in an inconsistent state. > >>>>> + * > >>>>> + * This function is only guaranteed to succeed if handles are destroyed in > >>>>> + * reverse order of their creation. > >>>> > >>>> How can the application find this information out on error? > >>> > >>> Without maintaining a list, they cannot. The specified case is the only > >>> possible guarantee. That does not mean PMDs should not do their best to > >>> destroy flow rules, only that ordering must remain consistent in case of > >>> inability to destroy one. > >>> > >>> What do you suggest? > >> > >> I think if the app cannot remove a specific rule it may want to remove > >> all rules and deal with flows in software for a time. So once the app > >> knows it fails that should be enough. > > > > OK, then since destruction may return an error already, is it fine? > > Applications may call rte_flow_flush() (not supposed to fail unless there is > > a serious issue, abort() in that case) and switch to SW fallback. > > yes, it's fine. > > > > > <...> > > >>>>> + * @param[out] error > >>>>> + * Perform verbose error reporting if not NULL. > >>>>> + * > >>>>> + * @return > >>>>> + * 0 on success, a negative errno value otherwise and rte_errno is set. > >>>>> + */ > >>>>> +int > >>>>> +rte_flow_query(uint8_t port_id, > >>>>> + struct rte_flow *flow, > >>>>> + enum rte_flow_action_type action, > >>>>> + void *data, > >>>>> + struct rte_flow_error *error); > >>>>> + > >>>>> +#ifdef __cplusplus > >>>>> +} > >>>>> +#endif > >>>> > >>>> I don't see a way to dump all the rules for a port out. I think this is > >>>> neccessary for degbugging. You could have a look through dpif.h in OVS > >>>> and see how dpif_flow_dump_next() is used, it might be a good reference. > >>> > >>> DPDK does not maintain flow rules and, depending on hardware capabilities > >>> and level of compliance, PMDs do not necessarily do it either, particularly > >>> since it requires space and application probably have a better method to > >>> store these pointers for their own needs. > >> > >> understood > >> > >>> > >>> What you see here is only a PMD interface. Depending on applications needs, > >>> generic helper functions built on top of these may be added to manage flow > >>> rules in the future. > >> > >> I'm thinking of the case where something goes wrong and I want to get a > >> dump of all the flow rules from hardware, not query the rules I think I > >> have. I don't see a way to do it or something to build a helper on top of? > > > > Generic helper functions would exist on top of this API and would likely > > maintain a list of flow rules themselves. The dump in that case would be > > entirely implemented in software. I think that recovering flow rules from HW > > may be complicated in many cases (even without taking storage allocation and > > rules conversion issues into account), therefore if there is really a need > > for it, we could perhaps add a dump() function that PMDs are free to > > implement later. > > > > ok. Maybe there are some more generic stats that can be got from the > hardware that would help debugging that would suffice, like total flow > rule hits/misses (i.e. not on a per flow rule basis). > > You can get this from the software flow caches and it's widely used for > debugging. e.g. > > pmd thread numa_id 0 core_id 3: > emc hits:0 > megaflow hits:0 > avg. subtable lookups per hit:0.00 > miss:0 > Perhaps a rule such as the following could do the trick: group: 42 (or priority 42) pattern: void actions: count / passthru Assuming useful flow rules are defined with higher priorities (using lower group ID or priority level) and provide a terminating action, this one would count all packets that were not caught by them. That is one example to illustrate how "global" counters can be requested by applications. Otherwise you could just make sure all rules contain mark / flag actions, in which case mbufs would tell directly if they went through them or need additional SW processing. -- Adrien Mazarguil 6WIND