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

Hi Luigi,

On 12 Nov 2014, at 00:00, Luigi Rizzo <rizzo_at_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 all the rest of the things that
> we normally find in an mbuf/skbuf ? This is not
> going to scale.

that's true.  I'm only suggesting a small extension to be used
freely, but would never consider increasing the slot size beyond
32 bytes in any case.  Keeping it sleek is obviously important.

> Also consider that at some point you may use a different
> arrangement (with packets passed along VALE switches
> or physical interfaces etc.) i believe the most
> reasonable place to put the extra info is at the end
> of the packet and possibly bump the length in the slot
> so you are safe in case the packet is copied.

I dont believe dirtying the cache lines in the actual packet
buffer is a wise choice, but it certainly works.

> There is no timestamp appended to the packet at the moment,
> it was a feature i thought somebody may want to have,
> but between the relative scarcity of hardware that provides
> per-packet timestamps, and the questionable usefulness
> of the same, i doubt it will be available.

It is a useful feature to have receive timestamps per packet
for better accounting, but I can see it being too mystical in
its current form inside the packet buffer.  It's still in my
TODO list to investigate the impact, but a system certainly
works without that extra bit of resolution.

For now, I'll go with Adrians suggestion and keep track of the
buffer index inside the first process away from netmap(4)
itself.  This setup breaks for non-circular pipe arrangements,
but the load-balancing use case at hand is alright.


Cheers,
Franco