Date: Tue, 11 Nov 2014 13:48:40 -0800 From: Adrian Chadd <adrian@freebsd.org> To: Franco Fichtner <franco@lastsummer.de> Cc: freebsd-current <freebsd-current@freebsd.org>, Luigi Rizzo <rizzo@iet.unipi.it> Subject: Re: netmap: extension to store user data per packet/slot? Message-ID: <CAJ-VmomLyE5to3hYDmhW%2B32j7UWo0fATPBxOTCiOfpCPytNcTQ@mail.gmail.com> In-Reply-To: <E4CF1489-B259-4ECE-9FFA-FD3850AE1DEC@lastsummer.de> References: <560E07EA-2506-487E-88DD-E2B9F7ED9792@lastsummer.de> <CAJ-Vmo=1XxdXNOBYR=_iXP-wEgNzYcBuy43TAE32O_5TnZ%2BT-w@mail.gmail.com> <E4CF1489-B259-4ECE-9FFA-FD3850AE1DEC@lastsummer.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11 November 2014 13:41, Franco Fichtner <franco@lastsummer.de> wrote: > Hi Adrian, > > On 11 Nov 2014, at 22:22, Adrian Chadd <adrian@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmomLyE5to3hYDmhW%2B32j7UWo0fATPBxOTCiOfpCPytNcTQ>