On 1/7/20 5:09 AM, Andrew Lunn wrote:

On Mon, Jan 06, 2020 at 07:43:48PM -0800, Shannon Nelson wrote:

quoted

Make sure the NIC drops packets that are larger than the
specified MTU.

The front end of the NIC will accept packets larger than MTU and
will copy all the data it can to fill up the driver's posted
buffers - if the buffers are not long enough the packet will
then get dropped.  With the Rx SG buffers allocagted as full
pages, we are currently setting up more space than MTU size
available and end up receiving some packets that are larger
than MTU, up to the size of buffers posted.  To be sure the
NIC doesn't waste our time with oversized packets we need to
lie a little in the SG descriptor about how long is the last
SG element.

Hi Shannon

Does the stack really drop them later? With DSA, the frame has an
additional header, making it longer than the MTU. Most of the NICs
i've used are happy to receive such frames. So it does seem common
practice to not implement a 'MRU' in the MAC.

If the stack really does drop them, this is a reasonable optimisation.

Thanks

	Andrew

Hi Andrew,

In my experience the driver typically tells the NIC about the current 
max_frame size (e.g. MTU + ETH_HLEN), the NIC only copies max_frame 
bytes, and the NIC returns an error indication on a packets that had 
more than max_frame.

Before this patch we were telling the Naples NIC of buffers that are 
longer than max_frame.  This NIC will happily accept oversized packets 
off of the wire and copy as much as it can into the buffers, and it will 
only set an error status when it runs out of buffer, not when it goes 
above max_frame size.  To get the "correct" behavior, we can't rely on 
setting max_frame, we have to rely on the buffer indications.

sln