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] [day] [month] [year] [list]
Date:   Wed, 24 Mar 2021 14:46:34 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Loic Poulain <loic.poulain@...aro.org>
Cc:     davem@...emloft.net, netdev@...r.kernel.org
Subject: Re: [RESEND PATCH net-next 2/2] net: mhi: proto_mbim: Adjust MTU
 and MRU

On Tue, 23 Mar 2021 15:45:07 +0100 Loic Poulain wrote:
> MBIM protocol makes the interface asymmetric, ingress data received
> from MHI is MBIM protocol, that can contain multiple aggregated IP
> packets, while egress data received from network stack is IP protocol.
> 
> Set a default MTU to 1500 (usual network MTU for WWAN), and MRU to 32K
> which is the default size of MBIM-over-MHI packets.
> 
> Signed-off-by: Loic Poulain <loic.poulain@...aro.org>
> ---
>  drivers/net/mhi/proto_mbim.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/net/mhi/proto_mbim.c b/drivers/net/mhi/proto_mbim.c
> index 75b5484..29d8577 100644
> --- a/drivers/net/mhi/proto_mbim.c
> +++ b/drivers/net/mhi/proto_mbim.c
> @@ -26,6 +26,9 @@
>  
>  #define MBIM_NDP16_SIGN_MASK 0x00ffffff
>  
> +#define MHI_MBIM_DEFAULT_MRU 32768
> +#define MHI_MBIM_DEFAULT_MTU 1500
> +
>  struct mbim_context {
>  	u16 rx_seq;
>  	u16 tx_seq;
> @@ -282,6 +285,8 @@ static int mbim_init(struct mhi_net_dev *mhi_netdev)
>  		return -ENOMEM;
>  
>  	ndev->needed_headroom = sizeof(struct mbim_tx_hdr);
> +	ndev->mtu = MHI_MBIM_DEFAULT_MTU;
> +	mhi_netdev->mru = MHI_MBIM_DEFAULT_MRU;
>  
>  	return 0;
>  }

32k + skb overhead will result in rather large contiguous allocation.
Using ~3.5k buffers (basically a page - paddings and skb_shinfo) should
be much more resilient, and still very efficient.

This sort of 32k buffer thing is common for USB, but I thought MHI is
over PCI so there should be no bus considerations once we're above 1k.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ