public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: 'Grygorii Strashko' <grygorii.strashko@ti.com>,
	"David S. Miller" <davem@davemloft.net>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Cc: Sekhar Nori <nsekhar@ti.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>
Subject: RE: [PATCH] net: ethernet: ti: cpsw: allow to configure min tx packet size
Date: Thu, 29 Nov 2018 12:24:41 +0000	[thread overview]
Message-ID: <59c91a27bb5b473fa5e1139016d3d825@AcuMS.aculab.com> (raw)
In-Reply-To: <20181125234315.28313-1-grygorii.strashko@ti.com>

From: Grygorii Strashko
> Sent: 25 November 2018 23:43
> 
> For proper VLAN packets forwarding CPSW driver uses min tx packet size of
> 64bytes (VLAN_ETH_ZLEN, excluding ETH_FCS) which was corrected by
> commit 9421c9015047 ("net: ethernet: ti: cpsw: fix min eth packet size").
> 
> Unfortunately, this breaks some industrial automation protocols, as
> reported by TI customers [1], which can work only with min TX packet size
> from 60 byte (ecluding FCS).

VLAN packets have the same minimal size as normal packets.
So they should (probably must) only be padded to 64 bytes (including the CRC).
Any hardware that strips a VLAN header would then need to add an extra
4 bytes of padding.

You can't assume that padding that makes an ethernet frame be longer
than 64 bytes (inc CRC) will be ignored by the receiving system.

So whatever make you think that 68 bytes was required is itself broken.

While most IP implementations will ignore extra padding this isn't
true of all protocols or implementations.
Unfortunately the fact that it is silently ignored causes the bugs
to be hidden.

We've recently discovered that some configurations of a VM system
cause all ethernet packets be padded to even length.
And yes, it broke things....

One of the very early ethernet chipsets could only transmit even
length packets - but I suspect they are all now in silicon heaven.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

      parent reply	other threads:[~2018-11-29 12:24 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-25 23:43 [PATCH] net: ethernet: ti: cpsw: allow to configure min tx packet size Grygorii Strashko
2018-11-26  2:27 ` Andrew Lunn
2018-11-28  1:27   ` Grygorii Strashko
2018-11-28  4:49     ` Andrew Lunn
2018-11-28 20:56       ` Grygorii Strashko
2018-11-28 22:02         ` Andrew Lunn
2018-11-28 22:43           ` Grygorii Strashko
2018-11-29  0:28             ` Andrew Lunn
2018-11-29  1:22               ` David Miller
2018-11-29 23:51                 ` Grygorii Strashko
2018-11-29 13:05   ` Lad, Prabhakar
2018-11-29 12:24 ` David Laight [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=59c91a27bb5b473fa5e1139016d3d825@AcuMS.aculab.com \
    --to=david.laight@aculab.com \
    --cc=davem@davemloft.net \
    --cc=grygorii.strashko@ti.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=nsekhar@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox