netdev - Re: XDP seeking input from NIC hardware vendors

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 8 Jul 2016 17:19:43 +0200
From:	Jesper Dangaard Brouer <brouer@...hat.com>
To:	Jakub Kicinski <jakub.kicinski@...ronome.com>
Cc:	Alexei Starovoitov <alexei.starovoitov@...il.com>,
	"Fastabend, John R" <john.r.fastabend@...el.com>,
	"iovisor-dev@...ts.iovisor.org" <iovisor-dev@...ts.iovisor.org>,
	Brenden Blanco <bblanco@...mgrid.com>,
	Rana Shahout <ranas@...lanox.com>, Ari Saha <as754m@....com>,
	Tariq Toukan <tariqt@...lanox.com>,
	Or Gerlitz <ogerlitz@...lanox.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Simon Horman <horms@...ge.net.au>,
	Simon Horman <simon.horman@...ronome.com>,
	Edward Cree <ecree@...arflare.com>, brouer@...hat.com
Subject: Re: XDP seeking input from NIC hardware vendors


On Fri, 8 Jul 2016 14:44:53 +0100 Jakub Kicinski <jakub.kicinski@...ronome.com> wrote:

> On Thu, 7 Jul 2016 19:22:12 -0700, Alexei Starovoitov wrote:
>
> > > If the goal is to just separate XDP traffic from non-XDP traffic
> > > you could accomplish this with a combination of SR-IOV/macvlan to
> > > separate the device queues into multiple netdevs and then run XDP
> > > on just one of the netdevs. Then use flow director (ethtool) or
> > > 'tc cls_u32/flower' to steer traffic to the netdev. This is how
> > > we support multiple networking stacks on one device by the way it
> > > is called the bifurcated driver. Its not too far of a stretch to
> > > think we could offload some simple XDP programs to program the
> > > splitting of traffic instead of cls_u32/flower/flow_director and
> > > then you would have a stack of XDP programs. One running in
> > > hardware and a set running on the queues in software.    
> > 
> >
> > the above sounds like much better approach then Jesper/mine
> > prog_per_ring stuff.
> >
> > If we can split the nic via sriov and have dedicated netdev via VF
> > just for XDP that's way cleaner approach. I guess we won't need to
> > do xdp_rxqmask after all.  
> 
> +1
> 
> I was thinking about using eBPF to direct to NIC queues but concluded
> that doing a redirect to a VF is cleaner.  Especially if the PF driver
> supports VF representatives we could potentially just use
> bpf_redirect(VFR netdev) and the VF doesn't even have to be handled by
> the same stack.

I actually disagree.

I _do_ want to use the "filter" part of eBPF to direct to NIC queues, and
then run a single/specific XDP program on that queue.

Why to I want this?

This part of solving a very fundamental CS problem (early demux), when
wanting to support Zero-copy on RX.  The basic problem that the NIC
driver need to map RX pages into the RX ring, prior to receiving
packets. Thus, we need HW support to steer packets, for gaining enough
isolation (e.g between tenants domains) for allowing zero-copy.


Based on the flexibility of the HW-filter, the granularity achievable
for isolation (e.g. application specific) is much more flexible.  Than
splitting up the entire NIC with SR-IOV, VFs or macvlans.

-- 
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