netdev - Re: [PATCH v3] Renesas Ethernet AVB driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <553804CA.1030605@cogentembedded.com>
Date:	Wed, 22 Apr 2015 23:30:02 +0300
From:	Sergei Shtylyov <sergei.shtylyov@...entembedded.com>
To:	David Miller <davem@...emloft.net>, mitsuhiro.kimura.kc@...esas.com
CC:	f.fainelli@...il.com, robh+dt@...nel.org, pawel.moll@....com,
	mark.rutland@....com, ijc+devicetree@...lion.org.uk,
	devicetree@...r.kernel.org, galak@...eaurora.org,
	netdev@...r.kernel.org, richardcochran@...il.com,
	linux-sh@...r.kernel.org, masaru.nagai.vx@...esas.com
Subject: Re: [PATCH v3] Renesas Ethernet AVB driver

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

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html