[dpdk-dev] [PATCH RFC 05/11] mbuf: merge physaddr and buf_len in a bitfield

Shaw, Jeffrey B jeffrey.b.shaw at intel.com
Fri May 9 18:11:59 CEST 2014


I agree, we should wait for comments then test the performance when the patches have settled.


-----Original Message-----
From: Olivier MATZ [mailto:olivier.matz at 6wind.com] 
Sent: Friday, May 09, 2014 9:06 AM
To: Shaw, Jeffrey B; dev at dpdk.org
Subject: Re: [dpdk-dev] [PATCH RFC 05/11] mbuf: merge physaddr and buf_len in a bitfield

Hi Jeff,

Thank you for your comment.

On 05/09/2014 05:39 PM, Shaw, Jeffrey B wrote:
> have you tested this patch to see if there is a negative impact to 
> performance?

Yes, but not with testpmd. I passed our internal non-regression performance tests and it shows no difference (or below the error margin), even with low overhead processing like forwarding whatever the number of cores I use.

> Wouldn't the processor have to mask the high bytes of the physical 
> address when it is used, for example, to populate descriptors with 
> buffer addresses?  When compute bound, this could steal CPU cycles 
> away from packet processing.  I think we should understand the 
> performance trade-off in order to save these 2 bytes.

I would naively say that the cost is negligible: accessing to the length is the same as before (it's a 16 bits field) and accessing the physical address is just a mask or a shift, which should not be very long on an Intel processor (1 cycle?). This is to be compared with the number of cycles per packet in io-fwd mode, which is probably around 150 or 200.

> It would be interesting to see how throughput is impacted when the 
> workload is core-bound.  This could be accomplished by running testpmd 
> in io-fwd mode across 4x 10G ports.

I agree, this is something we could check. If you agree, let's first wait for some other comments and see if we find a consensus on the patches.

Regards,
Olivier


More information about the dev mailing list