From: David L Stevens <david.stevens@oracle.com>
To: David Laight <David.Laight@ACULAB.COM>,
"'Raghuram Kothakota'" <Raghuram.Kothakota@oracle.com>
Cc: David Miller <davem@davemloft.net>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
Sowmini Varadhan <sowmini.varadhan@oracle.com>
Subject: Re: [PATCHv9 net-next 2/4] sunvnet: make transmit path zero-copy in the kernel
Date: Thu, 02 Oct 2014 07:33:14 -0400 [thread overview]
Message-ID: <542D37FA.3050708@oracle.com> (raw)
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D174A2CD2@AcuExch.aculab.com>
On 10/02/2014 05:06 AM, David Laight wrote:
>>> len = skb->len;
>>> - if (len < ETH_ZLEN) {
>>> + if (len < ETH_ZLEN)
>>> len = ETH_ZLEN;
>>> - memset(tx_buf+VNET_PACKET_SKIP+skb->len, 0, len - skb->len);
>>> +
>
> Aren't you transmitting 'random' bytes from the end of the data?
> Plausibly they might not even be mapped.
No. The checks to decide whether to copy or not make sure the
extra 6-14 bytes in the beginning and 0-8 bytes (for large frames, more
for small) at the end are part of the particular skb's headroom and
tailroom respectively. So, they aren't random bytes-- they are what
was allocated as part of the frame. For TCP streams, the trailing bytes
are likely part of the next packet. They definitely exist and are mapped,
but I don't zero them because they are usually COW and that forces a copy
every time.
>
> Also, for short frames the copy could well be faster - especially on systems
> with non-trivial iommu.
> It is also worth checking whether the original copy was aligned.
For the short frames, sure. I'm not sure what you mean by that last sentence--
the point of the checks that determine whether to copy or not are to enforce
alignment and length restrictions; if they aren't met in the original buffer,
we copy.
+-DLS
next prev parent reply other threads:[~2014-10-02 11:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-29 23:48 [PATCHv9 net-next 2/4] sunvnet: make transmit path zero-copy in the kernel David L Stevens
2014-10-02 5:50 ` Raghuram Kothakota
2014-10-02 9:06 ` David Laight
2014-10-02 11:33 ` David L Stevens [this message]
2014-10-02 11:11 ` David L Stevens
2014-10-02 23:11 ` Raghuram Kothakota
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=542D37FA.3050708@oracle.com \
--to=david.stevens@oracle.com \
--cc=David.Laight@ACULAB.COM \
--cc=Raghuram.Kothakota@oracle.com \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=sowmini.varadhan@oracle.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).