On Mon, 22 Aug 2016 14:57:00 -0700 Tom Herbert via iovisor-dev <iovisor-dev@lists.iovisor.org> wrote:
> On Mon, Aug 22, 2016 at 2:44 PM, Thomas Graf <tg...@suug.ch> wrote: > > 2016-08-09 17:47 GMT-04:00 Tom Herbert via iovisor-dev > > <iovisor-dev@lists.iovisor.org>: > >> Hi, > >> > >> I requested a workshop at netdev (Oct. 5-7 in Tokyo) to present and > >> showcase XDP. The goal of this is to start providing the public > >> information about XDP and to start talking about real world use cases > >> and development. > >> > >> I am looking for presenters of various topics in XDP. The content > >> might be similar to what we had at XDP summit, but the target audience > >> should be considered to be potentail users and programmers of XDP as > >> opposed to developers working on the infrastructure. > > [...] > > So far we'd have: > - Ceth > - Cilium > - ILA router/load balancer > > We should also have an overview and introduction to XDP. So I'm > thinking 30 minutes for intro/overview then 1 hr. for the above (e.g. > 20 minutes for each). I have a infrastructure related subject, that I would like to discuss during the XDP workshop. - "XDP port abstraction" Currently XDP only supports packet forwarding (back) out the incoming interface, this is rather limiting. Instead of doing something Linux specific like using the ifindex, I'm proposing to introduce what I call a XDP port abstraction. This is inspired by the mSwitch[1][2] paper (by Michio Honda). The basic idea: When loading a XDP program it register which port-abstraction table "instance" it is using (or creates a new instance). And as minimum register its own port, which also need to be provided as meta-data as "incoming-port" to the XDP program. The port-abstraction is a table lookup, and the XDP program simply returns an index into this table. The kernel handles forwarding between ports (mSwitch "fabric"), based on the port "type" in the table. XDP implements the "logic" behind the forwarding decision, and several XDP programs can share a bpf-map to synchronize their decisions/state. (See mSwitch data plane split between "fabric" and "logic"). The port "type" should be though as wide/abstract as possible. It should be easy to introduce a new "type" of port. An obvious "type" would be net_device, but the forwarding efficiency depend on what features or NDO-functions the specific net_device supports. I even imagine a socket could be a port-type. AFAIK Tom imagine a hardware specific port-type. Paper: [1] http://info.iet.unipi.it/~luigi/papers/20150617-mswitch-paper.pdf Slides: [2] http://www.slideshare.net/micchie/mswitch-paper-talk-at-sosr-2015 A side-note: the mSwitch paper also contains a novel approach of sorting and grouping incoming packets before forwarding. This is also something that is needed, but it is orthogonal to the port-abstraction table. -- 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
