Re: [dpdk-dev] [PATCH 0/3] net/virtio: make virtqueue struct cache-friendly

[Maxime Coquelin <maxime.coquelin@redhat.com>]

Hi Chenbo,

On 1/8/21 3:50 AM, Xia, Chenbo wrote:
> Hi Maxime,
> 
>> -----Original Message-----
>> From: Maxime Coquelin <maxime.coquelin@redhat.com>
>> Sent: Tuesday, December 22, 2020 12:15 AM
>> To: dev@dpdk.org; Xia, Chenbo <chenbo.xia@intel.com>; amorenoz@redhat.com;
>> david.marchand@redhat.com; olivier.matz@6wind.com
>> Cc: Maxime Coquelin <maxime.coquelin@redhat.com>
>> Subject: [PATCH 0/3] net/virtio: make virtqueue struct cache-friendly
>>
>> This series optimizes the cache usage of virtqueue struct,
>> by make a "fake" mbuf being dynamically allocated in Rx
>> virtnet struct, by removing a useless virtuque pointer
>> into the virtnet structs and by moving a few fields
>> to pack holes.
>>
>> With these 3 patches, the virtqueue struct size goes from
>> 576 bytes (9 cachelines) to 248 bytes (4 cachelines).
>>
>> Maxime Coquelin (3):
>>   net/virtio: remove reference to virtqueue in vrings
>>   net/virtio: allocate fake mbuf in Rx queue
>>   net/virtio: pack virtuqueue struct
>>
>>  drivers/net/virtio/virtio_ethdev.c            | 46 +++++++++++--------
>>  drivers/net/virtio/virtio_rxtx.c              | 36 +++++++--------
>>  drivers/net/virtio/virtio_rxtx.h              |  5 +-
>>  drivers/net/virtio/virtio_rxtx_packed_avx.c   | 14 +++---
>>  drivers/net/virtio/virtio_rxtx_simple.h       |  2 +-
>>  .../net/virtio/virtio_rxtx_simple_altivec.c   |  2 +-
>>  drivers/net/virtio/virtio_rxtx_simple_neon.c  |  2 +-
>>  drivers/net/virtio/virtio_rxtx_simple_sse.c   |  2 +-
>>  .../net/virtio/virtio_user/virtio_user_dev.c  |  4 +-
>>  drivers/net/virtio/virtio_user_ethdev.c       |  2 +-
>>  drivers/net/virtio/virtqueue.h                | 24 ++++++----
>>  11 files changed, 72 insertions(+), 67 deletions(-)
>>
>> --
>> 2.29.2
> 
> Does this patchset have a apply issue? Locally I can't apply the patches and
> Patchwork also shows apply issues.

For got to mention, but the series applied on top of the big rework as
it conflict with it, and the rework is more important.

Cheers,
Maxime

> Thanks,
> Chenbo
>