From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.49]) by dpdk.org (Postfix) with ESMTP id 4BD712B98 for ; Wed, 3 Aug 2016 17:19:42 +0200 (CEST) Received: by mail-wm0-f49.google.com with SMTP id f65so452289602wmi.0 for ; Wed, 03 Aug 2016 08:19:42 -0700 (PDT) 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:mail-followup-to:references :mime-version:content-disposition:in-reply-to; bh=A8Xzpa3t4wuK9Di1IBiaLhwHDVfKQ3CHBoA9nc2R6CA=; b=vAtLMk8aI/+rgrGGq6XjZ3VGwOS5tt8jo7tHxF40mKFilB7T4T3vRPuhw+kgVK82VV +q1brpzSP1qxqisjMN3WZlozKrKcr9TWd+IT/BWBRqCVsw/rIx2iICYPDVC/OqZsTSlE V0T9t8/Na/UEWkaLs3uZ5Y5SE3FVj+GBRYmG6HAejLHCkmfTUB3c3wbq8nk/yb0lsUvC jolVDA02gzZ7yiPrB+oNLnbgGE6bJGAuhKTl0Nu0InoB3BZAozB+x7pDGln7X7lUwHXe e3lldjCRsz3/Ene4oIsDg+1R7Vx0dfSPjQGSjdK6c1FHkelzDlAH5jJ+TeKLXp71251L sshQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to; bh=A8Xzpa3t4wuK9Di1IBiaLhwHDVfKQ3CHBoA9nc2R6CA=; b=Wqgi5jG/2YCMScqOXejOob4dSnJk61IGxE8qNF4LqTzirdu930wu1JSUPpW0mvAMkx p66sJJHy/TFhwDQ9Ih6rPUGlfefsP0Knbk6dTaKXRkhoVQC36EFiAsqieNEkab1XoEFQ cUY2OWkn7YJV6w45B75UX+KLzEdPB9gDh8qo/AP8tyIhH0RxZKONk58x0glhrRuUQfyI 8fodwM3o6EqUh7LqI4pgn2B3Bjyf5fKEnVVGDbA6Bmnbs2tWa5wRfS/IhtpN17yk1MJZ CHsaHovxH7bKjqL8kJw+OdL2/sHTYwbALjwr3ht9hvN99RbPuEOWwhOoK9gZpk94OaZt NUWg== X-Gm-Message-State: AEkoousqIET2olA5I7YEKf3QgFMvukA9ZMcPvX6QhNZ2KUQIGBkEHslbjaKb+ALeGIKV2wpp X-Received: by 10.28.37.194 with SMTP id l185mr53374056wml.82.1470237581274; Wed, 03 Aug 2016 08:19:41 -0700 (PDT) Received: from 6wind.com (guy78-3-82-239-227-177.fbx.proxad.net. [82.239.227.177]) by smtp.gmail.com with ESMTPSA id p3sm4668156wjb.45.2016.08.03.08.19.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Aug 2016 08:19:40 -0700 (PDT) Date: Wed, 3 Aug 2016 17:19:36 +0200 From: Adrien Mazarguil To: Kieran Mansley Cc: dev@dpdk.org Message-ID: <20160803151936.GG3336@6wind.com> Mail-Followup-To: Kieran Mansley , dev@dpdk.org References: <579F6603.4030801@solarflare.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <579F6603.4030801@solarflare.com> Subject: Re: [dpdk-dev] [RFC] Generic flow director/filtering/classification API X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 15:19:42 -0000 Hi Kieran, On Mon, Aug 01, 2016 at 04:08:51PM +0100, Kieran Mansley wrote: > Apologies for coming a little late to this thread about the proposed new > API for filtering etc. > > I've reviewed it based on Solarflare's needs and hardware capabilities, > and think the proposal is likely to be a big improvement on the current > system. > > I worry slightly that the goal of having applications that are not aware > of the hardware they are running on will be difficult to meet. My guess > is that the different hardware platforms will have so little overlap in > the functionality they support that to get best performance the > applications will still be heavily tailored to the subsets of the API > that the hardware they are using provides. The discussion of filter > priorities is a good example of this: to get best performance the > application will want to use the hardware's filtering capabilities to do > all the heavy lifting, but the abilities of different NICs to support > particular priorities and combinations of filters will mean what works > very well for one NIC may well return "I can't do that" for another, and > vice versa. I also think most applications will end up using mostly generic rules, while applications tailored for specific devices will use more features. In my mind this is like how applications would handle SSE/AVX/AltiVec/etc optimizations. They need to be aware such features exist and have both specific and more generic code. The query interface should help with that. > One suggestion for extending the API further would be to allow it to > also describe transmit filters as well as receive filters. Yes, TX is probably the next step. I think it will be part of the same API, using pattern/actions similarly only they would affect the TX path. But let's focus on the RX side for now. > There are also some filters that can prove very useful to our customers > that while they could be achieved through the careful insertion of > multiple filters with the right order and priorities, could be made more > application-friendly by having a more meaningful alias. For example: > - multicast-mismatch (all multicast traffic that doesn't match another > filter and would otherwise be discarded) > - unicast-mismatch (all unicast traffic that doesn't match another > filter and would otherwise be discarded) > - all-multicast (all multicast traffic) > - all-unicast (all unicast traffic) Why not, those may be added as new pattern items if the community feels they are necessary. But right now I do not think these are difficult to specify, of course one should dedicate priority levels far apart to avoid collisions with more specific rules, but you still need priorities to determine which of "all-multicast" or "unicast-mistmatch" should match first. > Finally, I wonder if any thought has been given to dealing with > situations where there is a conflict between different virtual or > physical functions. E.g. attempting to insert a MAC filter on one VF > that would steal traffic destined to a different VF. Will it be up to > each driver to enforce these sorts of policies or will there be a > general vendor-neutral framework to deal with this? PFs and VFs are a complex topic eh? Considering it is not even guaranteed for a PF to be able to see VF-addressed traffic as is currently the case for mlx4 and mlx5 (AFAIK). It will be up to each PMD, but they must all follow the same logic. A flow rule with a VF pattern item should not be allowed on a PF device if the PF is either unable to receive VF-addressed traffic, or if doing so would prevent traffic from being received by a VF when the flow rule specifies that it is supposed to pass through (either implictly or through a VF action). Simply matching the MAC address of a VF from a PF (without specifying the VF pattern item) should be allowed though. It may not work as packets may not be received at all, but if it does the application should take care of the consequences as VF may not receive packets anymore. Creating or updating the MAC address of a VF after adding a conflicting flow rule on a PF should not be allowed or remain undefined. All of this is not described in the specification yet because PF/VF patterns and actions are not fully defined at the moment, there is still some uncertainty about them. > I should reiterate that I think this will be a big improvement, so thank > you for proposing it. Thanks! -- Adrien Mazarguil 6WIND