On 11 November 2014 13:41, Franco Fichtner <fra...@lastsummer.de> wrote:
> Hi Adrian,
> On 11 Nov 2014, at 22:22, Adrian Chadd <adr...@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.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"