linux-kernel - Re: [PATCH] usb/gadget/function/u

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]

Date:	Thu, 3 Sep 2015 11:36:15 +0200
From:	Mike Looijmans <mike.looijmans@...ic.nl>
To:	<balbi@...com>, <gregkh@...uxfoundation.org>
CC:	<linux-usb@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] usb/gadget/function/u_ether.c: Allow jumbo frames

I'd like to bring this to your attention again please.

If there is something wrong about this patch, please tell me so.

And also note that this patch does not enable jumbo frames on itself, it just 
removes the artificial limits in the kernel prohibiting mtus above 1500. The 
MTU can be set from user space, and the impact on performance is quite impressive.

On 05-08-15 08:54, Mike Looijmans wrote:
> USB network adapters support Jumbo frames. The only thing blocking
> that feature is the code in the gadget driver that disposes of
> packets larger than 1518 bytes, and the limit on the ioctl to set
> the mtu.
>
> This patch relaxes these limits, and allows up to 15k frames sizes.
> The 15k value was chosen because 16k does not work on all platforms,
> and usingclose to 16k will result in allocating 5 or 8 4k pages to
> store the skb, wasting pages at no measurable performance gain.
>
> On a topic-miami board (Zynq-7000), iperf3 performance reports:
> MTU= 1500, PC-to-gadget: 139 Mbps, Gadget-to-PC: 116 Mbps
> MTU=15000, PC-to-gadget: 239 Mbps, Gadget-to-PC: 361 Mbps
>
> On boards with slower CPUs the performance improvement will be
> relatively much larger, e.g. an OMAP-L138 increased from 40 to
> 220 Mbps using a similar patch on an  2.6.37 kernel.
>
> Signed-off-by: Mike Looijmans <mike.looijmans@...ic.nl>
> ---
>   drivers/usb/gadget/function/u_ether.c | 9 +++++++--
>   1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/gadget/function/u_ether.c b/drivers/usb/gadget/function/u_ether.c
> index f1fd777..6828ea2 100644
> --- a/drivers/usb/gadget/function/u_ether.c
> +++ b/drivers/usb/gadget/function/u_ether.c
> @@ -48,6 +48,11 @@
>
>   #define UETH__VERSION	"29-May-2008"
>
> +/* Experiments show that both Linux and Windows hosts allow up to 16k
> + * frame sizes. Set the max size to 15k+52 to prevent allocating 32k
> + * blocks and still have efficient handling. */
> +#define GETHER_MAX_ETH_FRAME_LEN 15412
> +
>   struct eth_dev {
>   	/* lock is held while accessing port_usb
>   	 */
> @@ -146,7 +151,7 @@ static int ueth_change_mtu(struct net_device *net, int new_mtu)
>   	spin_lock_irqsave(&dev->lock, flags);
>   	if (dev->port_usb)
>   		status = -EBUSY;
> -	else if (new_mtu <= ETH_HLEN || new_mtu > ETH_FRAME_LEN)
> +	else if (new_mtu <= ETH_HLEN || new_mtu > GETHER_MAX_ETH_FRAME_LEN)
>   		status = -ERANGE;
>   	else
>   		net->mtu = new_mtu;
> @@ -294,7 +299,7 @@ static void rx_complete(struct usb_ep *ep, struct usb_request *req)
>   		while (skb2) {
>   			if (status < 0
>   					|| ETH_HLEN > skb2->len
> -					|| skb2->len > VLAN_ETH_FRAME_LEN) {
> +					|| skb2->len > GETHER_MAX_ETH_FRAME_LEN) {
>   				dev->net->stats.rx_errors++;
>   				dev->net->stats.rx_length_errors++;
>   				DBG(dev, "rx length %d\n", skb2->len);
>



Kind regards,

Mike Looijmans
System Expert

TOPIC Embedded Products
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
Telefax: +31 (0) 499 33 69 70
E-mail: mike.looijmans@...icproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/