DPDK patches and discussions
 help / color / mirror / Atom feed
From: Maxime Coquelin <maxime.coquelin@redhat.com>
To: "Yang, Zhiyong" <zhiyong.yang@intel.com>,
	Yuanhan Liu <yuanhan.liu@linux.intel.com>
Cc: "Liang, Cunming" <cunming.liang@intel.com>,
	"Tan, Jianfeng" <jianfeng.tan@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [RFC PATCH] net/virtio: Align Virtio-net header on cache line in receive path
Date: Wed, 22 Feb 2017 10:39:42 +0100	[thread overview]
Message-ID: <458456c8-57e7-94f3-a145-f73f66106418@redhat.com> (raw)
In-Reply-To: <E182254E98A5DA4EB1E657AC7CB9BD2A3EB7257A@BGSMSX101.gar.corp.intel.com>



On 02/22/2017 03:49 AM, Yang, Zhiyong wrote:
>
>> -----Original Message-----
>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Yuanhan Liu
>> Sent: Wednesday, February 22, 2017 9:38 AM
>> To: Maxime Coquelin <maxime.coquelin@redhat.com>
>> Cc: Liang, Cunming <cunming.liang@intel.com>; Tan, Jianfeng
>> <jianfeng.tan@intel.com>; dev@dpdk.org
>> Subject: Re: [dpdk-dev] [RFC PATCH] net/virtio: Align Virtio-net header on
>> cache line in receive path
>>
>> On Tue, Feb 21, 2017 at 06:32:43PM +0100, Maxime Coquelin wrote:
>>> This patch aligns the Virtio-net header on a cache-line boundary to
>>> optimize cache utilization, as it puts the Virtio-net header (which is
>>> always accessed) on the same cache line as the packet header.
>>>
>>> For example with an application that forwards packets at L2 level, a
>>> single cache-line will be accessed with this patch, instead of two
>>> before.
>>
>> I'm assuming you were testing pkt size <= (64 - hdr_size)?
>>
>>> In case of multi-buffers packets, next segments will be aligned on a
>>> cache-line boundary, instead of cache-line boundary minus size of vnet
>>> header before.
>>
>> The another thing is, this patch always makes the pkt data cache unaligned
>> for the first packet, which makes Zhihong's optimization on memcpy (for big
>> packet) useless.
>
> Why not could  we keep pkt data starting always on  the cache-line boundary?
> In case of multi-buffer, the first remains unchanged, next segments can do as
> Maxime said that.

This is not possible to have both the first and next buffers aligned on 
cache line boundary, as we don't know whether the deccriptor will be the 
first one, or a subsequent one on Virtio side when we refill the vq.

Cheers,
Maxime

>
> Thanks
> Zhiyong
>

  reply	other threads:[~2017-02-22  9:39 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-21 17:32 Maxime Coquelin
2017-02-22  1:37 ` Yuanhan Liu
2017-02-22  2:49   ` Yang, Zhiyong
2017-02-22  9:39     ` Maxime Coquelin [this message]
2017-02-22  9:36   ` Maxime Coquelin
2017-02-23  5:49     ` Yuanhan Liu
2017-03-01  7:36       ` Maxime Coquelin
2017-03-06  8:46         ` Yuanhan Liu
2017-03-06 14:11           ` Maxime Coquelin
2017-03-08  6:01             ` Yao, Lei A
2017-03-09 14:38               ` Maxime Coquelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=458456c8-57e7-94f3-a145-f73f66106418@redhat.com \
    --to=maxime.coquelin@redhat.com \
    --cc=cunming.liang@intel.com \
    --cc=dev@dpdk.org \
    --cc=jianfeng.tan@intel.com \
    --cc=yuanhan.liu@linux.intel.com \
    --cc=zhiyong.yang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).