netdev - Re: [RESEND PATCH net-next 2/2] net: mhi: proto

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]

Message-ID: <20210324144634.15234869@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>
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.