All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.