Re: netmap: extension to store user data per packet/slot?

Hi Adrian,

On 11 Nov 2014, at 22:22, Adrian Chadd <adrian_at_freebsd.org> wrote:

> ... I'm confused. Do you have the slot id already, right? Why not
> allocate an array of userdata pointers somewhere else and just use the
> netmap slot id as an indirection into that?

The slot id is per ring and there are a lot of them.  In case of
zero-copy the slot changes at least 1.  Consider two processes
for the load balancing case.  Process 1 attaches to the devices
and Process 2 only has a a pipe pair for receiving and sending
packets back to Process 1 after processing, because only that
process has access to the real devices:

em0, em1, etc. <--RX/TX--> Process 1 <--pipe pair--> Process 2
(Hardware)                (Balancer)                  (Worker)

There is no way to trace packet origin back to em0 or em1 after
pushing the packets through the pipe pair unless either the
pipes are unique for each device or there is another means to
keep its state.

Should, however, the buffer id be unique that would make it
easy to do what you suggest, but I don't know the netmap(4)
internals by heart.

It seems a wee unnatural to rebuild tracing of packets in
userland when netmap(4) has all the infrastructure needed to
deal with this effectively, but I'm not opposed to doing that
to avoid API/ABI changes.  Speaking of those, should volatile
internals change regarding the buffer id that would also break
the attempts to deal with the issue consistently.


Cheers,
Franco