[dpdk-dev] [PATCH RFC 06/11] mbuf: replace data pointer by an offset

[Olivier MATZ]

Hi Venky,

On 05/12/2014 04:41 PM, Neil Horman wrote:
>> This is a hugely problematic change, and has a pretty large
>> performance impact (because the dependency to compute and access). We
>> debated this for a long time during the early days of DPDK and
>> decided against it. This is also a repeated sequence - the driver
>> will do it twice (Rx + Tx) and the next level stack will do it twice
>> (Rx + Tx) ...
>>
>> My vote is to reject this change particular change to the mbuf.
>>
>> Regards,
>> -Venky
>>
> Do you have perforamance numbers to compare throughput with and without this
> change?  I always feel suspcious when I see the spectre of performane used to
> support or deny a change without supporting reasoning or metrics.

I agree with Neil. My feeling is that it won't impact performance, and
it is correlated with the forwarding tests I've done with this patch.

I don't really understand what would cost more by storing the offset
instead of the virtual address. I agree that each time the stack will
access to the begining of the mbuf, there will be an arithmetic
operation, but it is compensated by other operations that will be
accelerated:

- When receiving a packet, the driver will do:

     m->data_off = RTE_PKTMBUF_HEADROOM;

   instead of:

     m->data = (char*) rxm->buf_addr + RTE_PKTMBUF_HEADROOM;

- Each time the stack will prepend data, it has to check if the headroom
   is large enough to do the operation. This will be faster as data_off
   is the headroom.

- When transmitting a packet, the driver will get the physical address:

     phys_addr = m->buf_physaddr + m->data_off

   instead of:

     phys_addr = (m->buf_physaddr +  \
         ((char *)m->data - (char *)m->buf_addr)))

Moreover, these operations look negligible to me (few cycles) compared
to the large amount of arithmetic operations and tests done in the
driver.

Regards,
Olivier