Patchwork vlan: Support sending custom Ethernet CRC.

login
register
mail settings
Submitter Ben Greear
Date March 6, 2012, 2:05 a.m.
Message ID <1330999558-14270-1-git-send-email-greearb@candelatech.com>
Download mbox | patch
Permalink /patch/144828/
State Changes Requested
Delegated to: David Miller
Headers show

Comments

Ben Greear - March 6, 2012, 2:05 a.m.
From: Ben Greear <greearb@candelatech.com>

If the underlying device supports sending custom Ethernet CRC,
then enable that feature in the VLANs as well.

NOTE:  You will probably have to disable any
VLAN hardware assist on the underlying device to get
this to properly send packets with this feature enabled.

Signed-off-by: Ben Greear <greearb@candelatech.com>
---
:100644 100644 9988d4a... 6aeb0a3... M	net/8021q/vlan_dev.c
 net/8021q/vlan_dev.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)
David Miller - March 6, 2012, 2:14 a.m.
From: greearb@candelatech.com
Date: Mon,  5 Mar 2012 18:05:58 -0800

> NOTE:  You will probably have to disable any
> VLAN hardware assist on the underlying device to get
> this to properly send packets with this feature enabled.

This need to be therefore handled specifically on a device-by-device
basis, and VLAN custom CRC disabled unless the device explicitly
states that it can handle this situation properly and has any
necessary feature rule enforcement codified.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Ben Greear - March 6, 2012, 3:59 a.m.
On 03/05/2012 06:14 PM, David Miller wrote:
> From: greearb@candelatech.com
> Date: Mon,  5 Mar 2012 18:05:58 -0800
>
>> NOTE:  You will probably have to disable any
>> VLAN hardware assist on the underlying device to get
>> this to properly send packets with this feature enabled.
>
> This need to be therefore handled specifically on a device-by-device
> basis, and VLAN custom CRC disabled unless the device explicitly
> states that it can handle this situation properly and has any
> necessary feature rule enforcement codified.

I'll see what I can come up with.  Maybe figure out how to propagate
a flag up from the NIC when it is in a state that can handle VLAN + custom-CRC
and only enable the flag on the VLAN in that case...

Thanks,
Ben
David Miller - March 6, 2012, 4:12 a.m.
From: Ben Greear <greearb@candelatech.com>
Date: Mon, 05 Mar 2012 19:59:57 -0800

> On 03/05/2012 06:14 PM, David Miller wrote:
>> From: greearb@candelatech.com
>> Date: Mon,  5 Mar 2012 18:05:58 -0800
>>
>>> NOTE:  You will probably have to disable any
>>> VLAN hardware assist on the underlying device to get
>>> this to properly send packets with this feature enabled.
>>
>> This need to be therefore handled specifically on a device-by-device
>> basis, and VLAN custom CRC disabled unless the device explicitly
>> states that it can handle this situation properly and has any
>> necessary feature rule enforcement codified.
> 
> I'll see what I can come up with.  Maybe figure out how to propagate
> a flag up from the NIC when it is in a state that can handle VLAN +
> custom-CRC
> and only enable the flag on the VLAN in that case...

NETIF_F_CAN_VLAN_WITH_CUSTOM_CRC
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Ben Hutchings - March 6, 2012, 4:16 p.m.
On Mon, 2012-03-05 at 23:12 -0500, David Miller wrote:
> From: Ben Greear <greearb@candelatech.com>
> Date: Mon, 05 Mar 2012 19:59:57 -0800
> 
> > On 03/05/2012 06:14 PM, David Miller wrote:
> >> From: greearb@candelatech.com
> >> Date: Mon,  5 Mar 2012 18:05:58 -0800
> >>
> >>> NOTE:  You will probably have to disable any
> >>> VLAN hardware assist on the underlying device to get
> >>> this to properly send packets with this feature enabled.
> >>
> >> This need to be therefore handled specifically on a device-by-device
> >> basis, and VLAN custom CRC disabled unless the device explicitly
> >> states that it can handle this situation properly and has any
> >> necessary feature rule enforcement codified.
> > 
> > I'll see what I can come up with.  Maybe figure out how to propagate
> > a flag up from the NIC when it is in a state that can handle VLAN +
> > custom-CRC
> > and only enable the flag on the VLAN in that case...
> 
> NETIF_F_CAN_VLAN_WITH_CUSTOM_CRC

Er... vlan_features?

Ben.
David Miller - March 6, 2012, 7:36 p.m.
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Tue, 6 Mar 2012 16:16:34 +0000

> On Mon, 2012-03-05 at 23:12 -0500, David Miller wrote:
>> From: Ben Greear <greearb@candelatech.com>
>> Date: Mon, 05 Mar 2012 19:59:57 -0800
>> 
>> > On 03/05/2012 06:14 PM, David Miller wrote:
>> >> From: greearb@candelatech.com
>> >> Date: Mon,  5 Mar 2012 18:05:58 -0800
>> >>
>> >>> NOTE:  You will probably have to disable any
>> >>> VLAN hardware assist on the underlying device to get
>> >>> this to properly send packets with this feature enabled.
>> >>
>> >> This need to be therefore handled specifically on a device-by-device
>> >> basis, and VLAN custom CRC disabled unless the device explicitly
>> >> states that it can handle this situation properly and has any
>> >> necessary feature rule enforcement codified.
>> > 
>> > I'll see what I can come up with.  Maybe figure out how to propagate
>> > a flag up from the NIC when it is in a state that can handle VLAN +
>> > custom-CRC
>> > and only enable the flag on the VLAN in that case...
>> 
>> NETIF_F_CAN_VLAN_WITH_CUSTOM_CRC
> 
> Er... vlan_features?

Right.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index 9988d4a..6aeb0a3 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -543,6 +543,9 @@  static int vlan_dev_init(struct net_device *dev)
 	dev->features |= real_dev->vlan_features | NETIF_F_LLTX;
 	dev->gso_max_size = real_dev->gso_max_size;
 
+	if (netif_supports_nofcs(real_dev))
+		dev->priv_flags |= IFF_SUPP_NOFCS;
+
 	/* ipv6 shared card related stuff */
 	dev->dev_id = real_dev->dev_id;