From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id AB96495EA for ; Tue, 23 Dec 2014 10:30:20 +0100 (CET) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga103.jf.intel.com with ESMTP; 23 Dec 2014 01:27:44 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.07,630,1413270000"; d="scan'208";a="658939873" Received: from unknown ([10.243.20.17]) by orsmga002.jf.intel.com with SMTP; 23 Dec 2014 01:30:16 -0800 Received: by (sSMTP sendmail emulation); Tue, 23 Dec 2014 09:30:15 +0025 Date: Tue, 23 Dec 2014 09:30:15 +0000 From: Bruce Richardson To: Vithal S Mohare Message-ID: <20141223093015.GD10244@bricha3-MOBL3> References: <1419266844-4848-1-git-send-email-bruce.richardson@intel.com> <98DB008FA2AC6644B40AD8C766FAB271014BDE376A@BOREAL.arubanetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <98DB008FA2AC6644B40AD8C766FAB271014BDE376A@BOREAL.arubanetworks.com> Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH RFC 0/3] DPDK ethdev callback support 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: Tue, 23 Dec 2014 09:30:21 -0000 On Tue, Dec 23, 2014 at 04:23:21AM +0000, Vithal S Mohare wrote: > Hi Bruce, > > > For example, for a port type that does not support RSS, a callback on RX can be configured to calculate a hash in software. > > > Wondering if this callback will also be useful to bridge the gap of no RSS support for L2 packets. i.e. in the rx call-back handler, can applications calculate hash and feed it back so that spraying happens based on this? Now, all pure L2 packets (e.g. arp pkts) comes to rx-q 0 of the 'port'. Adding callback to [port][rx-q:0] would help? > > Thanks, > -Vithal Yes, that could work. The downside is that it is no faster than having an app do the calculation itself, it's just perhaps a little easier to work with in the app. /Bruce > > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Bruce Richardson > Sent: Monday, December 22, 2014 10:17 PM > To: dev@dpdk.org > Subject: [dpdk-dev] [PATCH RFC 0/3] DPDK ethdev callback support > > This RFC is for a small addition to the ethdev library, to add in support for callbacks at the RX and TX stages. This allows packet processing to be done on packets before they get returned to applications using rte_eth_rx_burst call. > > Use case: the first use case for this is to enable a consistent set of packets mbufs to be received by applications irrespective of the NIC used to receive those. For example, for a port type that does not support RSS, a callback on RX can be configured to calculate a hash in software. > Similarly, this mechanism can be used to add other information to mbufs as they are received, such as timestamps or sequence numbers, without cluttering up the main packet processing path with checks for whether packets have these fields filled in or not. > A second use case is ease of intrumenting existing code. The example application shows how combining a timestamp insertion callback on RX can be paired with a latency calculation callback on TX to easily instrument any application for packet latency. > A third use case is to potentially extend existing NIC capabilities beyond what is currently supported. For example, where flow director capabilities can match up to a certain limit of flows - in the thousands, in the case of NICs using the ixgbe driver - a callback can extend this to potentially millions of flows by using a software hash table lookup inline for packets that missing the hardware lookup filters. It would all appear transparent to the packet handling code in the main application. > > Future extensions: in future the ethdev library can be extended to provide a standard set of callbacks for use by drivers. > > For now this patch set is RFC and still needs additional work for creating a remove function for callbacks and to add in additional testing code. > Since this adds in new code into the critical data path, I have run some performance tests using testpmd with the ixgbe vector drivers (i.e. the fastest, fast-path we have :-) ). Performance drops due to this patch seems minimal to non-existant, rough tests on my system indicate a drop of perhaps 1%. > > All feedback welcome. > > Bruce Richardson (3): > ethdev: rename callbacks field to intr_cbs > ethdev: Add in data rxtx callback support > examples: example showing use of callbacks. > > app/test/virtual_pmd.c | 2 +- > examples/rxtx_callbacks/Makefile | 57 +++++++++ > examples/rxtx_callbacks/basicfwd.c | 222 +++++++++++++++++++++++++++++++++ > examples/rxtx_callbacks/basicfwd.h | 46 +++++++ > lib/librte_ether/rte_ethdev.c | 103 +++++++++++++-- > lib/librte_ether/rte_ethdev.h | 125 ++++++++++++++++++- > lib/librte_pmd_bond/rte_eth_bond_api.c | 2 +- > 7 files changed, 543 insertions(+), 14 deletions(-) create mode 100644 examples/rxtx_callbacks/Makefile create mode 100644 examples/rxtx_callbacks/basicfwd.c > create mode 100644 examples/rxtx_callbacks/basicfwd.h > > -- > 1.9.3 >