On Tue, 26 Jul 2016 10:53:05 -0700 John Fastabend <john.fastab...@gmail.com> wrote:
> On 16-07-26 09:08 AM, Tom Herbert wrote: > > On Tue, Jul 26, 2016 at 6:31 AM, Thomas Monjalon > > <thomas.monja...@6wind.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 _______________________________________________ iovisor-dev mailing list iovisor-dev@lists.iovisor.org https://lists.iovisor.org/mailman/listinfo/iovisor-dev
