[dpdk-dev] [RFC 0/8] mbuf: structure reorganization

Olivier MATZ olivier.matz at 6wind.com
Tue Feb 21 10:54:06 CET 2017


Hi Morten,

On Tue, 21 Feb 2017 10:22:57 +0100, Morten Brørup
<mb at smartsharesystems.com> wrote:
> Hi Olivier,
> 
> There has been a lot of debate about the size and location (1st or
> 2nd cache line) of the mbuf fields.
> 
> May I suggest that you add a comment to each field briefly mentioning
> why it has a specific size (8 or 16 bits) (e.g. by example use case),
> and optionally also why it deserves to be in the first cache line. (A
> comment to the mbuf structure can say that fields manipulated by PMDs
> on ingress generally belong in the 1st cache line.)
> 
> It's not necessary for all fields, just the non-obvious ones (the
> ones discussed here on the mailing list). It will make the
> information more easily accessible to avoid repeating the same
> discussions in the future.
> 
> E.g. the port field is 16 bits because a hypervisor can serve more
> than 256 virtual machines. And it is in the 1st cache line because a
> PMD for a multi-port NIC with a shared ingress queue needs to set it
> on ingress.
> 
> And the refcnt field has the same size as the port field to support
> L3 multicast and L2 port flooding on all ports.
> 

I understand your point about not rediscussing things several times. I
don't think having a comment for fields is really relevant because it
would add many info that are not useful for the user of the structure,
but I think adding something in the API documentation of the rte_mbuf
structure itself makes sense to me.

I'll add something in the next version of the patch.

Thanks,
Olivier



More information about the dev mailing list