devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
To: David Miller <davem@davemloft.net>, mitsuhiro.kimura.kc@renesas.com
Cc: f.fainelli@gmail.com, robh+dt@kernel.org, pawel.moll@arm.com,
	mark.rutland@arm.com, ijc+devicetree@hellion.org.uk,
	devicetree@vger.kernel.org, galak@codeaurora.org,
	netdev@vger.kernel.org, richardcochran@gmail.com,
	linux-sh@vger.kernel.org, masaru.nagai.vx@renesas.com
Subject: Re: [PATCH v3] Renesas Ethernet AVB driver
Date: Wed, 22 Apr 2015 23:30:02 +0300	[thread overview]
Message-ID: <553804CA.1030605@cogentembedded.com> (raw)
In-Reply-To: <20150422.113654.1169277303695917496.davem@davemloft.net>

Hello.

On 04/22/2015 06:36 PM, David Miller wrote:

>>>>> +		if (!ravb_tx_free(ndev, q)) {
>>>>> +			netif_warn(priv, tx_queued, ndev, "TX FD exhausted.\n");
>>>>> +			netif_stop_queue(ndev);
>>>>> +			spin_unlock_irqrestore(&priv->lock, flags);
>>>>> +			return NETDEV_TX_BUSY;
>>>>> +		}
>>>>> +	}
>>>>> +	entry = priv->cur_tx[q] % priv->num_tx_ring[q];
>>>>> +	priv->cur_tx[q]++;
>>>>> +	spin_unlock_irqrestore(&priv->lock, flags);
>>>>> +
>>>>> +	if (skb_put_padto(skb, ETH_ZLEN))
>>>>> +		return NETDEV_TX_OK;
>>>>> +
>>>>> +	priv->tx_skb[q][entry] = skb;
>>>>> +	buffer = PTR_ALIGN(priv->tx_buffers[q][entry], RAVB_ALIGN);
>>>>> +	memcpy(buffer, skb->data, skb->len);

>>>> ~1500 bytes memcpy(), not good...

>>>      I'm looking in the manual and not finding the hard requirement to have the
>>> buffer address aligned to 128 bytes (RAVB_ALIGN), sigh... Kimura-san?

>> There are the hardware requirement that the frame data must be aligned with
>> a 32-bit boundary in the URAM, see section 45A.3.3.1 Data Representation
>> in the manual.
>> I think that the original skb->data is almost aligned with 2 bytes boundary
>> by NET_IP_ALING, so we copied original skb->data to the local aligned buffer.

>> In addition, see section 45A.3.3.12 Tips for Optimizing Performance in Handling
>> Descriptors, it mentioned that frame data is accessed in blocks up to 128 bytes
>> and the number of 128 byte borders (addresses H'xxx00 and H'xxx80) and frame data
>> inside should be minimized.
>> So we set RAVB_ALIGN to 128 bytes.

> There is no way that copying is going to be faster than finding an adequate way
> to transmit directly out of the SKB memory.

> In this day and age there is simply no excuse for something like this, you will
> have to find a way.

    Hmm, I've been digging in the net core, and was unable to see where TX 
skb's get their NET_IP_ALIGN bytes reserved. Have I missed something? Probably 
need to print out skb's fields...

WBR, Sergei


  reply	other threads:[~2015-04-22 20:30 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-13 22:07 [PATCH v3] Renesas Ethernet AVB driver Sergei Shtylyov
2015-04-13 22:38 ` Florian Fainelli
2015-04-14 21:37   ` Sergei Shtylyov
2015-04-22  5:04     ` MITSUHIRO KIMURA
2015-04-22 15:36       ` David Miller
2015-04-22 20:30         ` Sergei Shtylyov [this message]
2015-04-22 20:42           ` David Miller
2015-04-22 20:46             ` Sergei Shtylyov
2015-04-22 22:17               ` David Miller
2015-04-22 21:38             ` Sergei Shtylyov
2015-04-22 22:18               ` David Miller
2015-04-22 22:34                 ` Sergei Shtylyov
2015-04-22 22:41                   ` David Miller
2015-04-22 22:50                     ` Sergei Shtylyov
2015-04-24  9:03               ` David Laight
2015-04-24 18:27                 ` Sergei Shtylyov
2015-04-27  9:22                   ` David Laight
2015-04-22 23:22     ` Florian Fainelli
2015-04-24 18:53       ` Sergei Shtylyov
2015-04-28 17:09         ` Ben Hutchings
2015-05-07 21:10         ` Sergei Shtylyov
2015-05-07 21:25           ` Sergei Shtylyov
2015-04-14  0:49 ` Lino Sanfilippo
2015-04-14 11:31   ` David Laight
2015-04-19 22:10   ` Sergei Shtylyov
2015-04-19 23:45     ` Lino Sanfilippo
2015-04-19  9:19 ` Richard Cochran

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=553804CA.1030605@cogentembedded.com \
    --to=sergei.shtylyov@cogentembedded.com \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=f.fainelli@gmail.com \
    --cc=galak@codeaurora.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=linux-sh@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=masaru.nagai.vx@renesas.com \
    --cc=mitsuhiro.kimura.kc@renesas.com \
    --cc=netdev@vger.kernel.org \
    --cc=pawel.moll@arm.com \
    --cc=richardcochran@gmail.com \
    --cc=robh+dt@kernel.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).