From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nbfkord-smmo01.seg.att.com (nbfkord-smmo01.seg.att.com [209.65.160.76]) by dpdk.org (Postfix) with ESMTP id 8A69E591F for ; Mon, 1 Aug 2016 17:28:20 +0200 (CEST) Received: from unknown [193.34.186.16] by nbfkord-smmo01.seg.att.com(mxl_mta-7.2.4-7) with SMTP id 39a6f975.0.596449.00-2329.1239015.nbfkord-smmo01.seg.att.com (envelope-from ); Mon, 01 Aug 2016 15:28:20 +0000 (UTC) X-MXL-Hash: 579f6a94105e757d-a5939ae8e03e19ecba3f233eed9899f0b33f763b Received: from kjm-desktop.uk.level5networks.com (10.17.20.160) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Mon, 1 Aug 2016 16:08:55 +0100 To: CC: From: Kieran Mansley Message-ID: <579F6603.4030801@solarflare.com> Date: Mon, 1 Aug 2016 16:08:51 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.17.20.160] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-11.0.0.1191-8.000.1202-22486.003 X-TM-AS-Result: No--5.404200-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No X-AnalysisOut: [v=2.1 cv=YvYJMtsX c=1 sm=1 tr=0 a=8P+NB+fYZDP74ap4g4d9Kw==] X-AnalysisOut: [:17 a=nFyVa_IFdnUA:10 a=IkcTkHD0fZMA:10 a=7z1cN_iqozsA:10 ] X-AnalysisOut: [a=_3rc1rOWg8W0DxLl2fkA:9 a=QEXdDO2ut3YA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2015072901)] X-MAIL-FROM: X-SOURCE-IP: [193.34.186.16] 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: Mon, 01 Aug 2016 15:28:21 -0000 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. One suggestion for extending the API further would be to allow it to also describe transmit filters as well as receive filters. 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) 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? I should reiterate that I think this will be a big improvement, so thank you for proposing it. Kieran The information contained in this message is confidential and is intended f= or the addressee(s) only. If you have received this message in error, pleas= e notify the sender immediately and delete the message. Unless you are an a= ddressee (or authorized to receive for an addressee), you may not use, copy= or disclose to anyone this message or any information contained in this me= ssage. The unauthorized use, disclosure, copying or alteration of this mess= age is strictly prohibited.