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, 26 Mar 2015 05:05:37 -0700
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Jonathan Davies <jonathan.davies@...rix.com>
Cc:	netdev@...r.kernel.org, xen-devel@...ts.xenproject.org,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	Boris Ostrovsky <boris.ostrovsky@...cle.com>,
	David Vrabel <david.vrabel@...rix.com>,
	Wei Liu <wei.liu2@...rix.com>
Subject: Re: [PATCH] xen-netfront: transmit fully GSO-sized packets

On Thu, 2015-03-26 at 11:13 +0000, Jonathan Davies wrote:
> xen-netfront limits transmitted skbs to be at most 44 segments in size. However,
> GSO permits up to 65536 bytes, which means a maximum of 45 segments of 1448
> bytes each. This slight reduction in the size of packets means a slight loss in
> efficiency.
> 
> Since c/s 9ecd1a75d, xen-netfront sets gso_max_size to
>     XEN_NETIF_MAX_TX_SIZE - MAX_TCP_HEADER,
> where XEN_NETIF_MAX_TX_SIZE is 65535 bytes.
> 
> The calculation used by tcp_tso_autosize (and also tcp_xmit_size_goal since c/s
> 6c09fa09d) in determining when to split an skb into two is
>     sk->sk_gso_max_size - 1 - MAX_TCP_HEADER.
> 
> So the maximum permitted size of an skb is calculated to be
>     (XEN_NETIF_MAX_TX_SIZE - MAX_TCP_HEADER) - 1 - MAX_TCP_HEADER.
> 
> Intuitively, this looks like the wrong formula -- we don't need two TCP headers.
> Instead, there is no need to deviate from the default gso_max_size of 65536 as
> this already accommodates the size of the header.
> 
> Currently, the largest skb transmitted by netfront is 63712 bytes (44 segments
> of 1448 bytes each), as observed via tcpdump. This patch makes netfront send
> skbs of up to 65160 bytes (45 segments of 1448 bytes each).
> 
> Fixes: 9ecd1a75d977 ("xen-netfront: reduce gso_max_size to account for max TCP header")
> Signed-off-by: Jonathan Davies <jonathan.davies@...rix.com>
> ---
>  drivers/net/xen-netfront.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
> index e9b960f..fb6e978 100644
> --- a/drivers/net/xen-netfront.c
> +++ b/drivers/net/xen-netfront.c
> @@ -1279,8 +1279,6 @@ static struct net_device *xennet_create_dev(struct xenbus_device *dev)
>  	netdev->ethtool_ops = &xennet_ethtool_ops;
>  	SET_NETDEV_DEV(netdev, &dev->dev);
>  
> -	netif_set_gso_max_size(netdev, XEN_NETIF_MAX_TX_SIZE - MAX_TCP_HEADER);
> -
>  	np->netdev = netdev;
>  
>  	netif_carrier_off(netdev);

Hmm, this partially reverts commit
9ecd1a75d977e2e8c48139c7d3efed183f898d94



Why xennet_change_mtu() is not changed by your patch ?



--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ