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

On 11 November 2014 13:41, Franco Fichtner <franco_at_lastsummer.de> wrote:
> 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.

Ah, I see. You're missing some unique identifier for each netmap
buffer. I thought there was one already. Silly me.

Luigi?



-adrian