DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Xie, Huawei" <huawei.xie@intel.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v2 0/5] virtio: Tx performance improvements
Date: Tue, 27 Oct 2015 02:38:24 +0000	[thread overview]
Message-ID: <C37D651A908B024F974696C65296B57B4B144E40@SHSMSX101.ccr.corp.intel.com> (raw)
In-Reply-To: <CAOaVG15O59cJc7ktFczr5cLCeNLo2zY5Md-ab56ZA3Q2RP6v9w@mail.gmail.com>

On 10/27/2015 10:23 AM, Stephen Hemminger wrote:
> You need to use the extended mergeable rx buffer format.
> It is a virtio spec requirement, look at Linux virtio network driver
> or ask the virtio maintainers for Linux
> if you need more clarification.
Yes, it is spec requirement as far as we know though num_buffers might
not be used.
So far not a big deal for us. Let us get clarification from mst later.
>
> On Tue, Oct 27, 2015 at 10:56 AM, Xie, Huawei <huawei.xie@intel.com
> <mailto:huawei.xie@intel.com>> wrote:
>
>     On 10/27/2015 7:52 AM, Stephen Hemminger wrote:
>     > On Fri, 23 Oct 2015 09:00:38 +0000
>     > "Xie, Huawei" <huawei.xie@intel.com
>     <mailto:huawei.xie@intel.com>> wrote:
>     >
>     >>>> Why use merge-able rx header here in the tx region?
>     >>> If mergeable rx is negotiated then the header must be used for
>     >>> both Tx and Rx. I chose to allocate the largest possible header
>     >>> needed, rather than having to deal with variable size data
>     structure.
>     >> Our original code is also using merge-able header for TX
>     descriptor if
>     >> this negotiated.
>     >> I checked the virtio spec, all of the merge-able header is about
>     >> receiving buffers, which is expected. That is why i feel weird
>     here.
>     >> Maybe not a big deal?
>     > Since num_buffers is only in merge-able header, the negotiation
>     is implied
>     > to be symmetric.
>     >
>     Can we come to the conclusion that in tx case, we use merge-able
>     header
>     though number_buffers is not used at all?
>     > Reading 0.95 spec
>     >
>     > Under "Packet Transmission"
>     >  3. If the driver negotatied the VIRTIO_NET_F_MGR_RXBUF feature
>     >     the num_buffers field is set to zero.
>     >
>     >
>
>


  reply	other threads:[~2015-10-27  2:38 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-19  5:16 Stephen Hemminger
2015-10-19  5:16 ` [dpdk-dev] [PATCH 1/5] virtio: clean up space checks on xmit Stephen Hemminger
2015-10-19  8:02   ` Xie, Huawei
2015-10-19 15:48     ` Stephen Hemminger
2015-10-19 16:27       ` Xie, Huawei
2015-10-19  5:16 ` [dpdk-dev] [PATCH 2/5] virtio: don't use unlikely for normal tx stuff Stephen Hemminger
2015-10-19  5:16 ` [dpdk-dev] [PATCH 3/5] virtio: use indirect ring elements Stephen Hemminger
2015-10-19 13:19   ` Xie, Huawei
2015-10-19 15:47     ` Stephen Hemminger
2015-10-19 16:18       ` Xie, Huawei
2015-10-30 18:01   ` Thomas Monjalon
2015-10-19  5:16 ` [dpdk-dev] [PATCH 4/5] virtio: use any layout on transmit Stephen Hemminger
2015-10-19 16:28   ` Xie, Huawei
2015-10-19 16:43     ` Stephen Hemminger
2015-10-19 16:56       ` Xie, Huawei
2015-10-26 23:47         ` Stephen Hemminger
2015-10-19 17:19     ` Stephen Hemminger
2015-10-19  5:16 ` [dpdk-dev] [PATCH 5/5] virtio: optimize transmit enqueue Stephen Hemminger
2015-10-20  1:48   ` Xie, Huawei
2015-10-21 13:18 ` [dpdk-dev] [PATCH v2 0/5] virtio: Tx performance improvements Thomas Monjalon
2015-10-22 10:38   ` Xie, Huawei
2015-10-22 12:13     ` Xie, Huawei
2015-10-22 16:04     ` Stephen Hemminger
2015-10-23  9:00       ` Xie, Huawei
2015-10-26 23:52         ` Stephen Hemminger
2015-10-27  1:56           ` Xie, Huawei
2015-10-27  2:23             ` Stephen Hemminger
2015-10-27  2:38               ` Xie, Huawei [this message]
2015-10-26 14:05 ` Xie, Huawei
2016-01-05  8:10   ` Xie, Huawei
2016-01-06 12:03     ` Thomas Monjalon
2016-01-14 13:49       ` Xie, Huawei
2016-03-04  6:18         ` Xie, Huawei
2016-03-04 18:17           ` Stephen Hemminger
2016-03-08  1:38             ` Xie, Huawei

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=C37D651A908B024F974696C65296B57B4B144E40@SHSMSX101.ccr.corp.intel.com \
    --to=huawei.xie@intel.com \
    --cc=dev@dpdk.org \
    --cc=stephen@networkplumber.org \
    /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).