From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
To: David Laight <David.Laight@ACULAB.COM>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Cc: "linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>
Subject: Re: [PATCH v2] ravb: minimize TX data copying
Date: Mon, 27 Jul 2015 11:57:33 +0000 [thread overview]
Message-ID: <55B61CAD.1010009@cogentembedded.com> (raw)
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1CB6C651@AcuExch.aculab.com>
On 7/27/2015 11:47 AM, David Laight wrote:
>> Renesas Ethernet AVB controller requires that all data are aligned on 4-byte
>> boundary. While it's easily achievable for the RX data with the help of
>> skb_reserve() (we even align on 128-byte boundary as recommended by the manual),
>> we can't do the same with the TX data, and it always comes unaligned from
>> the networking core. Originally we solved it an easy way, copying all packet
>> to a preallocated aligned buffer; however, it's enough to copy only up to
>> 3 first bytes from each packet, doing the transfer using 2 TX descriptors
>> instead of just 1. Here's an implementation of the new TX algorithm that
>> significantly reduces the driver's memory requirements.
> ...
>> - buffer = PTR_ALIGN(priv->tx_buffers[q][entry], RAVB_ALIGN);
>> - memcpy(buffer, skb->data, skb->len);
>> - desc = &priv->tx_ring[q][entry];
>> - desc->ds_tagl = cpu_to_le16(skb->len);
>> - dma_addr = dma_map_single(&ndev->dev, buffer, skb->len, DMA_TO_DEVICE);
>> + buffer = PTR_ALIGN(priv->tx_align[q], DPTR_ALIGN) +
>> + entry / NUM_TX_DESC * DPTR_ALIGN;
> The above would be clearer if tx_align was char[DPTR_ALIGN][].
tx_align is a pointer, not an array.
>> + len = PTR_ALIGN(skb->data, DPTR_ALIGN) - skb->data;
>> + memcpy(buffer, skb->data, len);
> Does this imply there has been an skb_linearize() ???
Sure, I don't support S/G (and it seems problematic given how the DMA
descriptors are handled by the h/w).
> The old version didn't really need it (it was doing a copy anyway).
It did since it copied the whole packet.
>> + dma_addr = dma_map_single(&ndev->dev, buffer, len, DMA_TO_DEVICE);
>> if (dma_mapping_error(&ndev->dev, dma_addr))
>> goto drop;
>> +
>> + desc = &priv->tx_ring[q][entry];
>> + desc->ds_tagl = cpu_to_le16(len);
>> + desc->dptr = cpu_to_le32(dma_addr);
>> +
>> + buffer = skb->data + len;
>> + len = skb->len - len;
>> + dma_addr = dma_map_single(&ndev->dev, buffer, len, DMA_TO_DEVICE);
>> + if (dma_mapping_error(&ndev->dev, dma_addr))
>> + goto unmap;
>> +
>> + desc++;
>> + desc->ds_tagl = cpu_to_le16(len);
> What happens if a fragment is less than DPTR_ALIGN bytes ???
It's always the case. If you mean a packet shorter than DPTR_ALIGN, it can
happen due to call to skb_put_padto(skb, ETH_ZLEN).
> Actually is looks like you relying on having a linear skb.
Yes, and I was relying on it even before this patch.
> David
WBR, Sergei
WARNING: multiple messages have this Message-ID (diff)
From: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
To: David Laight <David.Laight@ACULAB.COM>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Cc: "linux-sh@vger.kernel.org" <linux-sh@vger.kernel.org>
Subject: Re: [PATCH v2] ravb: minimize TX data copying
Date: Mon, 27 Jul 2015 14:57:33 +0300 [thread overview]
Message-ID: <55B61CAD.1010009@cogentembedded.com> (raw)
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1CB6C651@AcuExch.aculab.com>
On 7/27/2015 11:47 AM, David Laight wrote:
>> Renesas Ethernet AVB controller requires that all data are aligned on 4-byte
>> boundary. While it's easily achievable for the RX data with the help of
>> skb_reserve() (we even align on 128-byte boundary as recommended by the manual),
>> we can't do the same with the TX data, and it always comes unaligned from
>> the networking core. Originally we solved it an easy way, copying all packet
>> to a preallocated aligned buffer; however, it's enough to copy only up to
>> 3 first bytes from each packet, doing the transfer using 2 TX descriptors
>> instead of just 1. Here's an implementation of the new TX algorithm that
>> significantly reduces the driver's memory requirements.
> ...
>> - buffer = PTR_ALIGN(priv->tx_buffers[q][entry], RAVB_ALIGN);
>> - memcpy(buffer, skb->data, skb->len);
>> - desc = &priv->tx_ring[q][entry];
>> - desc->ds_tagl = cpu_to_le16(skb->len);
>> - dma_addr = dma_map_single(&ndev->dev, buffer, skb->len, DMA_TO_DEVICE);
>> + buffer = PTR_ALIGN(priv->tx_align[q], DPTR_ALIGN) +
>> + entry / NUM_TX_DESC * DPTR_ALIGN;
> The above would be clearer if tx_align was char[DPTR_ALIGN][].
tx_align is a pointer, not an array.
>> + len = PTR_ALIGN(skb->data, DPTR_ALIGN) - skb->data;
>> + memcpy(buffer, skb->data, len);
> Does this imply there has been an skb_linearize() ???
Sure, I don't support S/G (and it seems problematic given how the DMA
descriptors are handled by the h/w).
> The old version didn't really need it (it was doing a copy anyway).
It did since it copied the whole packet.
>> + dma_addr = dma_map_single(&ndev->dev, buffer, len, DMA_TO_DEVICE);
>> if (dma_mapping_error(&ndev->dev, dma_addr))
>> goto drop;
>> +
>> + desc = &priv->tx_ring[q][entry];
>> + desc->ds_tagl = cpu_to_le16(len);
>> + desc->dptr = cpu_to_le32(dma_addr);
>> +
>> + buffer = skb->data + len;
>> + len = skb->len - len;
>> + dma_addr = dma_map_single(&ndev->dev, buffer, len, DMA_TO_DEVICE);
>> + if (dma_mapping_error(&ndev->dev, dma_addr))
>> + goto unmap;
>> +
>> + desc++;
>> + desc->ds_tagl = cpu_to_le16(len);
> What happens if a fragment is less than DPTR_ALIGN bytes ???
It's always the case. If you mean a packet shorter than DPTR_ALIGN, it can
happen due to call to skb_put_padto(skb, ETH_ZLEN).
> Actually is looks like you relying on having a linear skb.
Yes, and I was relying on it even before this patch.
> David
WBR, Sergei
next prev parent reply other threads:[~2015-07-27 11:57 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-25 20:42 [PATCH v2] ravb: minimize TX data copying Sergei Shtylyov
2015-07-25 20:42 ` Sergei Shtylyov
2015-07-27 8:22 ` David Miller
2015-07-27 8:22 ` David Miller
2015-07-27 8:47 ` David Laight
2015-07-27 11:57 ` Sergei Shtylyov [this message]
2015-07-27 11:57 ` Sergei Shtylyov
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=55B61CAD.1010009@cogentembedded.com \
--to=sergei.shtylyov@cogentembedded.com \
--cc=David.Laight@ACULAB.COM \
--cc=linux-sh@vger.kernel.org \
--cc=netdev@vger.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 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.