On Sun, Apr 10, 2016 at 12:55 AM, Thomas Graf <tg...@suug.ch> wrote: > On 04/09/16 at 10:26am, Alexei Starovoitov wrote: >> On Sat, Apr 09, 2016 at 11:29:18AM -0400, Jamal Hadi Salim wrote: >> > If this is _forwarding only_ it maybe useful to look at >> > Alexey's old code in particular the DMA bits; >> > he built his own lookup algorithm but sounds like bpf is >> > a much better fit today. >> >> a link to these old bits? >> >> Just to be clear: this rfc is not the only thing we're considering. >> In particular huawei guys did a monster effort to improve performance >> in this area as well. We'll try to blend all the code together and >> pick what's the best. > > What's the plan on opening the discussion on this? Can we get a peek? > Is it an alternative to XDP and the driver hook? Different architecture > or just different implementation? I understood it as another pseudo > skb model with a path on converting to real skbs for stack processing. > We started discussions about this in IOvisor. The Huawei project is called ceth (Common Ethernet). It is essentially a layer called directly from drivers intended for fast path forwarding and network virtualization. They have put quite a bit of effort into buffer management and other parts of the infrastructure, much of which we would like to leverage in XDP. The code is currently in github, will ask them to make it generally accessible.
The programmability part, essentially BPF, should be part of a common solution. We can define the necessary interfaces independently of the underlying infrastructure which is really the only way we can do this if we want the BPF programs to be portable across different platforms-- in Linux, userspace, HW, etc. Tom > I really like the current proposal by Brenden for its simplicity and > targeted compatibility with cls_bpf.
