Hi Luigi, On Sat, Dec 17, 2011 at 12:28 AM, Luigi Rizzo <[email protected]> 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 <[email protected]> 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 > > > > [email protected] > > > > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > > > _______________________________________________ > > > click mailing list > > > [email protected] > > > https://amsterdam.lcs.mit.edu/mailman/listinfo/click > > > > _______________________________________________ click mailing list [email protected] https://amsterdam.lcs.mit.edu/mailman/listinfo/click
