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

2014-11-12 Thread Franco Fichtner
Hi Luigi, On 12 Nov 2014, at 00:00, Luigi Rizzo ri...@iet.unipi.it wrote: apparently you want some user-defined metadata to move along with the packet, but i do not think it is reasonable to put it in the slots. If we do that, what about timestamps, flow IDs, interface and queue index and

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

2014-11-12 Thread Slawa Olhovchenkov
On Tue, Nov 11, 2014 at 10:13:54PM +0100, Franco Fichtner wrote: Hi Luigi, hi all, so I was running into logistics issues with netmap(4) with regard to zero-copy and redirection through pipes: working on a load-balancing framework revealed that it is very hard to track a packet's origins

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

2014-11-12 Thread Luigi Rizzo
On Wed, Nov 12, 2014 at 11:16 AM, Slawa Olhovchenkov s...@zxy.spb.ru wrote: On Tue, Nov 11, 2014 at 10:13:54PM +0100, Franco Fichtner wrote: Hi Luigi, hi all, so I was running into logistics issues with netmap(4) with regard to zero-copy and redirection through pipes: working on a

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

2014-11-11 Thread Franco Fichtner
Hi Luigi, hi all, so I was running into logistics issues with netmap(4) with regard to zero-copy and redirection through pipes: working on a load-balancing framework revealed that it is very hard to track a packet's origins to later move it onward to the respective outgoing interface, be it

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

2014-11-11 Thread Adrian Chadd
... 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? -adrian On 11 November 2014 13:13, Franco Fichtner fra...@lastsummer.de wrote: Hi Luigi, hi all, so I was

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

2014-11-11 Thread Franco Fichtner
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

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

2014-11-11 Thread Adrian Chadd
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

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

2014-11-11 Thread Franco Fichtner
On 11 Nov 2014, at 22:48, Adrian Chadd adr...@freebsd.org wrote: Ah, I see. You're missing some unique identifier for each netmap buffer. I thought there was one already. Silly me. Exactly, and, no, thank you for making clear what is needed. :) A little more on this: I think struct

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

2014-11-11 Thread Luigi Rizzo
Franco, apparently you want some user-defined metadata to move along with the packet, but i do not think it is reasonable to put it in the slots. If we do that, what about timestamps, flow IDs, interface and queue index and all the rest of the things that we normally find in an mbuf/skbuf ? This