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).
Hence, introduce module boot parameter "tx_packet_min" to allow configure
min TX packet size at boot time.
[1] https://e2e.ti.com/support/arm/sitara_arm/f/791/t/701669
Fixes: 9421c9015047 ("net: ethernet: ti: cpsw: fix min eth packet size")
Signed-off-by: Grygorii Strashko <[email protected]>
---
drivers/net/ethernet/ti/cpsw.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index ceaec56..15d563c 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -188,6 +188,10 @@ static int rx_packet_max = CPSW_MAX_PACKET_SIZE;
module_param(rx_packet_max, int, 0);
MODULE_PARM_DESC(rx_packet_max, "maximum receive packet size (bytes)");
+static int tx_packet_min = CPSW_MIN_PACKET_SIZE;
+module_param(tx_packet_min, int, 0444);
+MODULE_PARM_DESC(tx_packet_min, "minimum tx packet size (bytes)");
+
static int descs_pool_size = CPSW_CPDMA_DESCS_POOL_SIZE_DEFAULT;
module_param(descs_pool_size, int, 0444);
MODULE_PARM_DESC(descs_pool_size, "Number of CPDMA CPPI descriptors in pool");
@@ -2131,7 +2135,7 @@ static netdev_tx_t cpsw_ndo_start_xmit(struct sk_buff *skb,
struct cpdma_chan *txch;
int ret, q_idx;
- if (skb_padto(skb, CPSW_MIN_PACKET_SIZE)) {
+ if (skb_padto(skb, tx_packet_min)) {
cpsw_err(priv, tx_err, "packet pad failed\n");
ndev->stats.tx_dropped++;
return NET_XMIT_DROP;
@@ -3636,7 +3640,7 @@ static int cpsw_probe(struct platform_device *pdev)
dma_params.num_chan = data->channels;
dma_params.has_soft_reset = true;
- dma_params.min_packet_size = CPSW_MIN_PACKET_SIZE;
+ dma_params.min_packet_size = tx_packet_min;
dma_params.desc_mem_size = data->bd_ram_size;
dma_params.desc_align = 16;
dma_params.has_ext_regs = true;
--
2.10.5
On Sun, Nov 25, 2018 at 05:43:15PM -0600, Grygorii Strashko wrote:
> 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).
Hi Grygorii
excluding...
> Hence, introduce module boot parameter "tx_packet_min" to allow configure
> min TX packet size at boot time.
Module parameters are generally not liked.
What actually happens here with this lower limit? Does the hardware
send runt packets? Does the protocol actually require runt packets?
I'm just wondering if the module parameter can be avoided by setting
this as the default. But we need to ensure ARP packets, which are
smaller than the minimum MTU are correctly padded.
Thanks
Andrew
Hi Andrew,
On 11/25/18 8:27 PM, Andrew Lunn wrote:
> On Sun, Nov 25, 2018 at 05:43:15PM -0600, Grygorii Strashko wrote:
>> 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).
>
> Hi Grygorii
>
> excluding...
>
>> Hence, introduce module boot parameter "tx_packet_min" to allow configure
>> min TX packet size at boot time.
>
> Module parameters are generally not liked.
not sure how to proceed otherwise. There is always one instance of CPSW per SoC,
so Module parameter is safe here at least.
>
> What actually happens here with this lower limit? Does the hardware
> send runt packets? Does the protocol actually require runt packets?
I do not have more details in addition to what's described in [1]:
"While for instance the ARP protocol does not seem to have a problem with additional
padding in the payload, some industrial automation protocols seem to be strict in this regard."
"We're basically running a bridge for different industrial protocols like ProfiNet"
As per my understanding there some industrial HW and SW which has very
strict limitation to min packet size and just can't handle other min packet
sizes.
>
> I'm just wondering if the module parameter can be avoided by setting
> this as the default.
It was a default value 60 bytes (64 bytes with FCS), but I changed it to 64 byte (68 byte with FCS)
as per above mentioned commit for proper VLAN tagged packets forwarding support
(which seems legal as per 802.1q - G.2.1 Treatment of PAD fields in IEEE 802.3 frames).
Use case:
- Port 0 (int) - vlan capable host.
- Port 1 (ext) - vlan capable network
- port 2 (ext)- non vlan capable network. pvid is set.
all egress traffic untagged. CPSW HW can't align packet properly
when vlan tag is removed, so need to use 68 byte min packet size.
Hence, both use cases need to be supported - this patch posted.
without it TI customers will continue do revert manually when required
which definitely not a good option.
>But we need to ensure ARP packets, which are
> smaller than the minimum MTU are correctly padded.
[1] https://e2e.ti.com/support/arm/sitara_arm/f/791/t/701669
--
regards,
-grygorii
> [1] https://e2e.ti.com/support/arm/sitara_arm/f/791/t/701669
Reading this, the interesting part is:
My guess would be that the driver would have to track the
configuration of the switch hardware to correctly pad the
frame.
Have you tried that?
Andrew
On 11/27/18 10:49 PM, Andrew Lunn wrote:
>> [1] https://e2e.ti.com/support/arm/sitara_arm/f/791/t/701669
>
> Reading this, the interesting part is:
>
> My guess would be that the driver would have to track the
> configuration of the switch hardware to correctly pad the
> frame.
>
> Have you tried that?
This is dynamic configuration related to ALE VLAN entries and
I do not see the way to support its auto-detection with current driver,
unfortunately.
--
regards,
-grygorii
> This is dynamic configuration related to ALE VLAN entries and
> I do not see the way to support its auto-detection with current driver,
> unfortunately.
I think you can subscribe to switchdev events which will tell you.
Andrew
Hi Andrew,
On 11/28/18 4:02 PM, Andrew Lunn wrote:
>> This is dynamic configuration related to ALE VLAN entries and
>> I do not see the way to support its auto-detection with current driver,
>> unfortunately.
>
> I think you can subscribe to switchdev events which will tell you.
Thanks a lot for your review and comments.
Unfortunately, we still do not have switchdev in place, but i need to resolve
existing issue somehow. This patch is small, local to CPSW fix which can be
backported to stable. So, if possible, and no strong objection, could we proceed with it?
--
regards,
-grygorii
On Wed, Nov 28, 2018 at 04:43:40PM -0600, Grygorii Strashko wrote:
> Hi Andrew,
>
> On 11/28/18 4:02 PM, Andrew Lunn wrote:
> >> This is dynamic configuration related to ALE VLAN entries and
> >> I do not see the way to support its auto-detection with current driver,
> >> unfortunately.
> >
> > I think you can subscribe to switchdev events which will tell you.
>
> Thanks a lot for your review and comments.
>
> Unfortunately, we still do not have switchdev in place, but i need to resolve
> existing issue somehow. This patch is small, local to CPSW fix which can be
> backported to stable. So, if possible, and no strong objection, could we proceed with it?
Hi Grygorii
David is the person who generally says no to kernel module
parameters. You should ask him.
Andrew
From: Andrew Lunn <[email protected]>
Date: Thu, 29 Nov 2018 01:28:35 +0100
> On Wed, Nov 28, 2018 at 04:43:40PM -0600, Grygorii Strashko wrote:
>> Hi Andrew,
>>
>> On 11/28/18 4:02 PM, Andrew Lunn wrote:
>> >> This is dynamic configuration related to ALE VLAN entries and
>> >> I do not see the way to support its auto-detection with current driver,
>> >> unfortunately.
>> >
>> > I think you can subscribe to switchdev events which will tell you.
>>
>> Thanks a lot for your review and comments.
>>
>> Unfortunately, we still do not have switchdev in place, but i need to resolve
>> existing issue somehow. This patch is small, local to CPSW fix which can be
>> backported to stable. So, if possible, and no strong objection, could we proceed with it?
>
> Hi Grygorii
>
> David is the person who generally says no to kernel module
> parameters. You should ask him.
No module options.
You'll be stuck with it forever.
Sorry.
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)
Hi Andrew,
On Mon, Nov 26, 2018 at 2:27 AM Andrew Lunn <[email protected]> wrote:
>
> On Sun, Nov 25, 2018 at 05:43:15PM -0600, Grygorii Strashko wrote:
> > 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).
>
> Hi Grygorii
>
> excluding...
>
> > Hence, introduce module boot parameter "tx_packet_min" to allow configure
> > min TX packet size at boot time.
>
> Module parameters are generally not liked.
>
> What actually happens here with this lower limit? Does the hardware
> send runt packets? Does the protocol actually require runt packets?
>
Yes it does send runt packets, and also get Rx align errors. you can
find the ethtool dump at [1].
[1] https://e2e.ti.com/support/processors/f/791/t/719557?Linux-AM5728-EtherCAT-packets-dropped
Cheers,
--Prabhakar Lad
Hi All,
On 11/28/18 7:22 PM, David Miller wrote:
> From: Andrew Lunn <[email protected]>
> Date: Thu, 29 Nov 2018 01:28:35 +0100
>
>> On Wed, Nov 28, 2018 at 04:43:40PM -0600, Grygorii Strashko wrote:
>>> Hi Andrew,
>>>
>>> On 11/28/18 4:02 PM, Andrew Lunn wrote:
>>>>> This is dynamic configuration related to ALE VLAN entries and
>>>>> I do not see the way to support its auto-detection with current driver,
>>>>> unfortunately.
>>>>
>>>> I think you can subscribe to switchdev events which will tell you.
>>>
>>> Thanks a lot for your review and comments.
>>>
>>> Unfortunately, we still do not have switchdev in place, but i need to resolve
>>> existing issue somehow. This patch is small, local to CPSW fix which can be
>>> backported to stable. So, if possible, and no strong objection, could we proceed with it?
>>
>> Hi Grygorii
>>
>> David is the person who generally says no to kernel module
>> parameters. You should ask him.
>
> No module options.
>
> You'll be stuck with it forever.
Thank you for your feedback.
--
regards,
-grygorii