From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f46.google.com (mail-wm0-f46.google.com [74.125.82.46]) by dpdk.org (Postfix) with ESMTP id 97FB82BD2 for ; Thu, 25 Feb 2016 19:26:28 +0100 (CET) Received: by mail-wm0-f46.google.com with SMTP id c200so41444648wme.0 for ; Thu, 25 Feb 2016 10:26:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:organization:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=QcwaUQNU4tI7mz6gUbmpkD/Yo1TVCXrs03A17jIQjUM=; b=YaIf0IJXT2GZaC3agDC6RD3flW+f3hzG0bSFp6d+39ODb1ujT+Unqxg4dsviGez92L XVAzPR1y8Dm5Dqkb5VNh4aW9riqQhlLtAXim8jb8HwFwd0OP3nxSk75m1zk89fva9nym y01KSQlHIgyiv8h+RQexWgQ3720KWsi/D+ngTYVlqobuPOU1vuoodlI/dkCWImock9kL dsUDv/99BQ8pDAZ1rDAxgsWfbz85tqt7QKdf+WGFioh5zbm8HkKUn1K6gd20xZ1XMKrP xvSOy8FhF0+63LzPSBpP1UpdRlTusR8ypWH4wKoM8i2bpleJHvkLRmS1Sqf16q+guJ2a +VWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding; bh=QcwaUQNU4tI7mz6gUbmpkD/Yo1TVCXrs03A17jIQjUM=; b=YZC7B2a8WafFriM5cfVEunL2mj130HrLNV6ZwIHDNluaMAMXMToNLTHdm51BB+PeBE 8uuLa7wxMgnmNblnijGjS9wuN2broFodxFICBcwpOf6isf54kX8MODB3n/FfBN+5Qo34 LPcYzDQLDvNNgK5Tqe9IGprGqOV0yog8Rd1/jYYaEbWCrATlo5YbtAbi6MofQWiiXGtG UCUpmUW3Tah0oftxLkvXuujnU6+OBzFazlCaw/iK077iuO4FFqhjTJNAzqOTSnXU8fMo E9F4cPcKPP6v8LCAjxwiU6WlWgjNGN3CttzwyLKdoRh0bWM7Lcvn01ZcM2iRXP/KAHNO kEww== X-Gm-Message-State: AG10YOS3Eq6Pd80JkTGo0Sg8s4UXEb6WXj7MLUYvZ+eRqPWeJL5PfzZeuDP+lUGmHRh1IBtA X-Received: by 10.28.224.84 with SMTP id x81mr95898wmg.62.1456424788421; Thu, 25 Feb 2016 10:26:28 -0800 (PST) Received: from xps13.localnet (171.36.101.84.rev.sfr.net. [84.101.36.171]) by smtp.gmail.com with ESMTPSA id w136sm4354129wmw.0.2016.02.25.10.26.26 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 25 Feb 2016 10:26:27 -0800 (PST) From: Thomas Monjalon To: Rahul Lakkireddy Date: Thu, 25 Feb 2016 19:24:54 +0100 Message-ID: <3876623.1zX8JlhDJf@xps13> Organization: 6WIND User-Agent: KMail/4.14.10 (Linux/4.1.6-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <20160225093322.GB10077@chelsio.com> References: <3102616.xnBgmsEaQs@xps13> <20160225093322.GB10077@chelsio.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org, Kumar A S , Nirranjan Kirubaharan Subject: Re: [dpdk-dev] [PATCH 01/10] ethdev: add a generic flow and new behavior switch to fdir 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: Thu, 25 Feb 2016 18:26:28 -0000 2016-02-25 15:03, Rahul Lakkireddy: > On Wednesday, February 02/24/16, 2016 at 14:17:58 -0800, Thomas Monjalon wrote: > > > A raw flow provides a generic way for vendors to add their vendor > > > specific input flow. > > > > Please, "generic" and "vendor specific" in the same sentence. > > It's obviously wrong. > > I think this sentence is being mis-interpreted. > What I intended to say is: the fields are generic so that any vendor can > hook-in. The fields themselves are not vendor specific. We are trying to push some features into fields of an API instead of thinking how to make it simple. > > > In our case, it is possible to match several flows > > > in a single rule. For example, it's possible to set an ethernet, vlan, > > > ip and tcp/udp flows all in a single rule. We can specify all of these > > > flows in a single raw input flow, which can then be passed to cxgbe flow > > > director to set the corresponding filter. > > > > I feel we need to define what is an API. > > If the application wants to call something specific to the NIC, why using > > the ethdev API? You just have to include cxgbe.h. > > Well, in that sense, flow-director is also very intel specific, no ? Yes. I think the term "flow director" comes from Intel. > What we are trying to do is make flow-director generic So let's stop calling it flow director. We are talking about filtering, right? > and, we have been > following the review comments on this. If there are better ideas on how > to achieve this, we are open to suggestions/comments and are ready to > re-do the series and re-submit also. My first question: are you happy with the current API? Do you understand the difference between RTE_ETH_FILTER_ETHERTYPE and RTE_ETH_FILTER_FDIR with RTE_ETH_FLOW_L2_PAYLOAD? Do you understand this structure? enum rte_eth_fdir_status { RTE_ETH_FDIR_NO_REPORT_STATUS = 0, /**< Report nothing. */ RTE_ETH_FDIR_REPORT_ID, /**< Only report FD ID. */ RTE_ETH_FDIR_REPORT_ID_FLEX_4, /**< Report FD ID and 4 flex bytes. */ RTE_ETH_FDIR_REPORT_FLEX_8, /**< Report 8 flex bytes. */ }; These values? enum rte_fdir_mode { RTE_FDIR_MODE_NONE = 0, /**< Disable FDIR support. */ RTE_FDIR_MODE_SIGNATURE, /**< Enable FDIR signature filter mode. */ RTE_FDIR_MODE_PERFECT, /**< Enable FDIR perfect filter mode. */ RTE_FDIR_MODE_PERFECT_MAC_VLAN, /**< Enable FDIR filter mode - MAC VLAN. */ RTE_FDIR_MODE_PERFECT_TUNNEL, /**< Enable FDIR filter mode - tunnel. */ }; >>From my point of view, it is insane. We have put the hardware complexity in the API. And now you want to put some vendor specific data in some fields like some black magic recipes. Why is it so complex? We are talking about packet filtering, not rocket science! > > I know the support of filters among NICs is really heterogeneous. > > And the DPDK API are not yet generic enough. But please do not give up! > > If the filtering API can be improved to support your cases, please do it. > > I am not giving up. If there are better suggestions then, I am willing > to re-do and re-submit the series. > If the approach taken in RFC v1 series looks more promising then, I can > re-surrect that also. However, I will need some direction over here so > that it becomes generic and doesn't remain intel specific as it is now. Yes the approach in the RFC was better in the sense it was describing the fields. But honestly, I'd prefer thinking of filtering from scratch. What is a hardware filter? (note there is no such doc yet) It matches a packet with some criterias and take an action on it. Simple. Now details (it can take weeks or months to list every details). A hardware implements a subset of the infinite capabilities. So the API must provide a flag to check a rule/action capability without really configuring it. A matching rule must match every criterias or only some of them (AND/OR operators). An action is associated to a matching rule. There can be several matching rules on the same port (Chelsio case?). Any packet field can be matched (we currently define some of them). An action can be of different types: - drop - switch - accept in any queue - accept in a specific queue Most of the rules give some values to match the fields. The hash filtering (RSS) specify only some fields and a key to direct packets in different queues. Please, Intel, Chelsio and other vendors, tell what is wrong above and let's start a sane discussion on hardware filtering. More background: The current API was designed by Intel when they were the only NIC vendor. Now that there are 8 vendors with different capabilities and that FPGA should bring even more capabilities, we should be able to build something more generic while being usable.