Message-ID: <20160726204203.452e988c@redhat.com>
Date:	Tue, 26 Jul 2016 20:42:03 +0200
From:	Jesper Dangaard Brouer <brouer@...hat.com>
To:	John Fastabend <john.fastabend@...il.com>
Cc:	Tom Herbert <tom@...bertland.com>,
	Thomas Monjalon <thomas.monjalon@...nd.com>,
	Tom Herbert via iovisor-dev <iovisor-dev@...ts.iovisor.org>,
	Jakub Kicinski <jakub.kicinski@...ronome.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"Fastabend, John R" <john.r.fastabend@...el.com>,
	Edward Cree <ecree@...arflare.com>,
	Simon Horman <simon.horman@...ronome.com>,
	Rana Shahout <ranas@...lanox.com>,
	Or Gerlitz <ogerlitz@...lanox.com>, Ari Saha <as754m@....com>,
	adrien.mazarguil@...nd.com, brouer@...hat.com
Subject: Re: [iovisor-dev] XDP seeking input from NIC hardware vendors

On Tue, 26 Jul 2016 10:53:05 -0700
John Fastabend <john.fastabend@...il.com> wrote:

> On 16-07-26 09:08 AM, Tom Herbert wrote:
> > On Tue, Jul 26, 2016 at 6:31 AM, Thomas Monjalon
> > <thomas.monjalon@...nd.com> wrote:  
> >> Hi,
> >>
> >> About RX filtering, there is an ongoing effort in DPDK to write an API
> >> which could leverage most of the hardware capabilities of any NICs:
> >>         https://rawgit.com/6WIND/rte_flow/master/rte_flow.html
> >>         http://thread.gmane.org/gmane.comp.networking.dpdk.devel/43352
> >> I understand that XDP does not target to support every hardware features,
> >> though it may be an interesting approach to check.
> >>  
> > Thomas,
> > 
> > A major goal of XDP is to leverage and in fact encourage innovation in
> > hardware features. But, we are asking that vendors design the APIs
> > with the community in mind. For instance, if XDP supports crypto
> > offload it should have one API that different companies, we don't want
> > every vendor coming up with their own.  
> 
> The work in those threads is to create a single API for users of DPDK
> to interact with their hardware. The equivalent interface in Linux
> kernel is ntuple filters from ethtool the effort here is to make a
> usable interface to manage this from an application and also expose
> all the hardware features. Ethtool does a fairly poor job on both
> fronts IMO.

Yes, the ethtool + ntuple approach is unfortunately not very easy to :-(


> If we evolve the mechanism to run per rx queue xdp programs this
> interface could easily be used to forward packets to specific rx
> queues and run targeted xdp programs.
> 
> Integrating this functionality into running XDP programs as ebpf code
> seems a bit challenging to me because there is no software equivalent.
> Once XDP ebpf program is running the pkt has already landed on the rx
> queue. To me the mechanism to bind XDP programs to rx queues and steer
> specific flows (e.g. match a flow label and forward to a queue) needs
> to be part of the runtime environment not part of the main ebpf program
> itself. 

I agree, based on the discussion in this thread. Will admit that my
initial idea of adding this filter to the eBPF/XDP program was not such
a good idea.

> The runtime environment could use the above linked API. I know
> we debated earlier including this in the ebpf program itself but that
> really doesn't seem feasible to me. Whether the steering is expresses
> as an ebpf program or an API like above seems like a reasonable
> discussion. Perhaps a section could be used to describe the per program
> filter for example which would be different from an API approach used
> in the proposal above or the JIT could translate it into the above
> API for devices without instruction based hardware.

It seems like someone actually put some though into this, in the link
you send... quite interesting, thanks:
 https://rawgit.com/6WIND/rte_flow/master/rte_flow.html

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  Author of http://www.iptv-analyzer.org
  LinkedIn: http://www.linkedin.com/in/brouer

Powered by blists - more mailing lists