From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Fastabend via iovisor-dev Subject: Re: XDP seeking input from NIC hardware vendors Date: Thu, 7 Jul 2016 14:33:14 -0700 Message-ID: <577ECA9A.2000307@gmail.com> References: <20160707124245.6d95635a@redhat.com> <20160707171246.5be5e433@jkicinski-Precision-T1700> Reply-To: John Fastabend Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: "netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "iovisor-dev-9jONkmmOlFHEE9lA1F8Ukti2O/JbrIOy@public.gmane.org" , "Fastabend, John R" , Edward Cree , Simon Horman , Rana Shahout , Or Gerlitz , Ari Saha To: Tom Herbert , Jakub Kicinski Return-path: In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iovisor-dev-bounces-9jONkmmOlFHEE9lA1F8Ukti2O/JbrIOy@public.gmane.org Errors-To: iovisor-dev-bounces-9jONkmmOlFHEE9lA1F8Ukti2O/JbrIOy@public.gmane.org List-Id: netdev.vger.kernel.org On 16-07-07 10:53 AM, Tom Herbert wrote: > On Thu, Jul 7, 2016 at 9:12 AM, Jakub Kicinski > wrote: >> On Thu, 7 Jul 2016 15:18:11 +0000, Fastabend, John R wrote: >>> The other interesting thing would be to do more than just packet >>> steering but actually run a more complete XDP program. Netronome >>> supports this right. The question I have though is this a stacked of >>> XDP programs one or more designated for hardware and some running in >>> software perhaps with some annotation in the program so the hardware >>> JIT knows where to place programs or do we expect the JIT itself to >>> try and decide what is best to offload. I think the easiest to start >>> with is to annotate the programs. >>> >>> Also as far as I know a lot of hardware can stick extra data to the >>> front or end of a packet so you could push metadata calculated by the >>> program here in a generic way without having to extend XDP defined >>> metadata structures. Another option is to DMA the metadata to a >>> specified address. With this metadata the consumer/producer XDP >>> programs have to agree on the format but no one else. >> >> Yes! >> >> At the XDP summit we were discussing pipe-lining XDP programs in >> general, with different stages of the pipeline potentially using >> specific hardware capabilities or even being directly mappable on >> fixed HW functions. >> >> Designating parsing as one of specialized blocks makes sense in a long >> run, probably at the first stage with recirculation possible. We also >> have some parsing HW we could utilize at some point. However, I'm >> worried that it's too early to impose constraints and APIs. I agree >> that we should first set a standard way to pass metadata across tail >> calls to facilitate any form of pipe lining, regardless of which parts >> of pipeline HW is able to offload. > > +1 > > I don't see any reason why XDP programs can be turned into a pipeline, > but this is implementation based on the output of one program being > the inout of the next. While XDP may work with pipeline it does not > require it or define it. This makes XDP different from P4 and the > match-action paradigm. > > Tom > Sounds like we all agree. Just a note, XDP is a reasonable target for P4 in fact we have a P4 to eBPF target already working. We may end up with a set of DSLs running on top of XDP where P4 is one of them. .John