From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jesper Dangaard Brouer Subject: Re: Focusing the XDP project Date: Wed, 22 Feb 2017 10:43:28 +0100 Message-ID: <20170222104328.4b9c6c5d@redhat.com> References: <20170220111343.76f77748@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Saeed Mahameed , Saeed Mahameed , Alexander Duyck , Alexei Starovoitov , John Fastabend , David Miller , "netdev@vger.kernel.org" , Brenden Blanco , brouer@redhat.com To: Tom Herbert Return-path: Received: from mx1.redhat.com ([209.132.183.28]:43194 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751347AbdBVJnd (ORCPT ); Wed, 22 Feb 2017 04:43:33 -0500 In-Reply-To: Sender: netdev-owner@vger.kernel.org List-ID: On Tue, 21 Feb 2017 14:54:35 -0800 Tom Herbert wrote: > On Tue, Feb 21, 2017 at 2:29 PM, Saeed Mahameed wrote: [...] > > The only complexity XDP is adding to the drivers is the constrains on > > RX memory management and memory model, calling the XDP program itself > > and handling the action is really a simple thing once you have the > > correct memory model. Exactly, that is why I've been looking at introducing a generic facility for a memory model for drivers. This should help simply drivers. Due to performance needs this need to be a very thin API layer on top of the page allocator. (That's why I'm working with Mel Gorman to get more close integration with the page allocator e.g. a bulking facility). > > Who knows! maybe someday XDP will define one unified RX API for all > > drivers and it even will handle normal stack delivery it self :). > > > That's exactly the point and what we need for TXDP. I'm missing why > doing this is such rocket science other than the fact that all these > drivers are vastly different and changing the existing API is > unpleasant. The only functional complexity I see in creating a generic > batching interface is handling return codes asynchronously. This is > entirely feasible though... I'll be happy as long as we get a batching interface, then we can incrementally do the optimizations later. In the future, I do hope (like Saeed) this RX API will evolve into delivering (a bulk of) raw-packet-pages into the netstack, this should simplify drivers, and we can keep the complexity and SKB allocations out of the drivers. To start with, we can play with doing this delivering (a bulk of) raw-packet-pages into Tom's TXDP engine/system? -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat LinkedIn: http://www.linkedin.com/in/brouer