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. Luigi? -adrian _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
