[Click] Re?: Re: Kernel mode with a recent kernel

[Beyers Cronje]

Hi Luigi,

On Sat, Dec 17, 2011 at 12:28 AM, Luigi Rizzo <rizzo at iet.unipi.it> wrote:

> On Fri, Dec 16, 2011 at 10:54:06PM +0200, Beyers Cronje wrote:
> > According to figure 5
> > http://info.iet.unipi.it/~luigi/netmap/20110729-rizzo-infocom.pdf  there
> > seems to be a significant improvement over netmapcap using native netmap
> > (7500kpps vs 9660kpps), so this sounds like a good idea.
>
> in terms of time it is only 20ns per packet :)
>
> Surely every little improvement counts, but probably it is more
> useful to extend the libpcap library to attach to individual rings,
> so you can run multiple threads in parallel without contention.
> It's a trivial change (the ring index can be part of the device
> name).
>
> To use efficiently the native API, click should use the buffers
> allocated by netmap instead of its own. I guess the in-kernel
> click does the same, using sk_buffs instead of allocating memory ?
>

That is correct, Click kernel module uses sk_buffs instead of allocating
packet data memory. However, userspace Click has a nice Packet::make
overload that takes a previous allocated buffer and a pointer to a
destructor function that gets called when the packet is killed. See
https://github.com/kohler/click/blob/master/include/click/packet.hh#L58
So you can use netmap buffers allocated to Click packet data, Click will
only allocate packet annotations and headers using the Click packet pool
but use netmap's buffer for the data payload.

Does netmap require in-order release of these buffers back to netmap? If so
the problem with this approach is when an element holds on to a packet for
an indefinite time, then the netmap buffer will obviously not be released
immediately. This is the same problem we are facing using a custom element
that receives packets from an Endace capture card. The Endace API requires
an application to release buffer space in ordered ranges as received by the
API, so we are forced to make expensive packet copies of any packet we want
to store for a period of time.

Beyers


>
> cheers
> luigi
>
> >
> > On Fri, Dec 16, 2011 at 9:08 PM, Eddie Kohler <ekohler at gmail.com> wrote:
> >
> > > Luigi,
> > >
> > > As you know I think this is awesome.
> > >
> > > Should we start working on a direct linkup between Click and netmap,
> rather
> > > than using libpcap as an intermediate?
> > >
> > > Eddie
> > >
> > >
> > > On 12/16/2011 10:32 AM, Luigi Rizzo wrote:
> > > > On Fri, Dec 16, 2011 at 03:57:00PM +0100, Fabrice Schuler wrote:
> > > >> Hi Eddy,
> > > >>
> > > >> Thanks for your answer.
> > > >>
> > > >> In a first time, we could probably only use kernel mode without
> > > polling, so patchless click could be fine. But on a longer run, I
> would say
> > > that yes, we will need polling mode.
> > > >> I will try patchless mode in a first time, and will still try to
> work
> > > to use polling in a second time.
> > > >
> > > > If you are interested in polling because of performance, you should
> > > > really consider using click-userspace with netmap (currently on
> > > > FreeBSD, but linux support is really close now)
> > > >
> > > > http://info.iet.unipi.it/~luigi/netmap/
> > > >
> > > > In our tests it seems to beat in-kernel click by a factor of 2,
> > > > for I/O intensive tasks (where polling makes the difference).
> > > >
> > > > http://info.iet.unipi.it/~luigi/netmap/20110729-rizzo-infocom.pdf
> > > >
> > > > cheers
> > > > luigi
> > > > _______________________________________________
> > > > click mailing list
> > > > click at amsterdam.lcs.mit.edu
> > > > https://amsterdam.lcs.mit.edu/mailman/listinfo/click
> > > _______________________________________________
> > > click mailing list
> > > click at amsterdam.lcs.mit.edu
> > > https://amsterdam.lcs.mit.edu/mailman/listinfo/click
> > >
>