RE: [PATCH net-next] net: hns3: Add support to change MTU in hardware & netdev

[Salil Mehta]

Hi Andrew

> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@xxxxxxx]
> Sent: Friday, August 18, 2017 4:04 PM
> To: Salil Mehta
> Cc: davem@xxxxxxxxxxxxx; Zhuangyuzeng (Yisen); lipeng (Y);
> dan.carpenter@xxxxxxxxxx; mehta.salil.lnk@xxxxxxxxx;
> netdev@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; linux-
> rdma@xxxxxxxxxxxxxxx; Linuxarm
> Subject: Re: [PATCH net-next] net: hns3: Add support to change MTU in
> hardware & netdev
> 
> > > > +	/* MTU range: 68 - 9706 */
> > > > +	netdev->min_mtu = ETH_MIN_MTU;
> > >
> > > http://elixir.free-
> > > electrons.com/linux/latest/source/net/ethernet/eth.c#L361
> > Supported range of Min and Max MTU should be at the discretion
> > of the driver. Therefore, initialization looks fine to me.
> >
> > I could not clearly understand the problem being highlighted
> > over here. Could you further clarify?
> 
> This is already setting min_mtu to ETH_MIN_MTU. There is no need for
> you to set it.
I grep'ed entire code and could see min and max MTUs being set by the
Respective Ethernet driver code. I also verified by the original patch
floated by the Jarod where he did that Change across all the drivers
https://patchwork.kernel.org/patch/9387361/

for example,
file: drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c
static int init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
 
 		netdev->priv_flags |= IFF_UNICAST_FLT;
 
+		/* MTU range: 81 - 9600 */
+		netdev->min_mtu = 81; 
+		netdev->max_mtu = MAX_MTU;

Many such changes are present in the above mentioned patch.
Hope I am not missing anything there?

Thanks
Salil
> 
> > > >  #define HNS3_RING_MAX_PENDING			32768
> > > > +#define HNS3_MAX_MTU				9728
> > >
> > > It seems odd that it does not already exists somewhere. The core
> does
> > > not enforce the MTU.  You could be passed a frame which is bigger.
> So
> > > you should check before trying to pass something to the hardware
> which
> > > the hardware cannot handle.
> > There is a check already in place for this as well since 4.10-rc1.
> 
> Yes, the core will check when changing the MTU.
> 
> But when passing frames to be transmitted, it does not check the frame
> fits the MTU.  DSA actually makes use of this, when passing frames to
> an Ethernet switch attached to the interface. We need to add an extra
> header to the frame, which makes the frame bigger than the MTU. Most
> Ethernet drivers are happy with this, they send the frame. Other
> reject it, and we have had to make driver changes. And some just
> explode :-(
I see. IMHO HNS3 is currently limited by maximum buffer per descriptor
which is 64k. I am sure such frames would get dropped in the hardware
itself and which I guess should be more preferable than dropping in
driver since it saves you some precious cpu cycles?

So I am not able to appreciate the presence of such a MTU check in
the live data-path. Maybe I am missing something here?

Thanks
Salil
> 
> If 9728 is a hard limit for your device, you should check when passed
> a frame to make sure it is actually <= 9728 bytes in length.
> 
>      Andrew