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


  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.