Re: DSA and underlying 802.1Q encapsulation
On 05/28/2015 06:44 AM, Vivien Didelot wrote: Hi Guenter, If yes, the dsa code may need to move the tag into the header. If we are lucky, a call to vlan_hwaccel_push_inside() might do it. Thanks, I'm currently looking into it and doing some tests, I'm coming back to you asap. Issue fixed, thanks! vlan_hwaccel_push_inside() adds additional memmove, but this approach is simpler. Do you have some vlan dsa code to share, by any chance ? That might save me some time, as I am looking into it as well. Yes, I am about the send an RFC for fully integrated 802.1q VLAN support on Marvell 88E6352 devices. Excellent, that is going to safe me a lot of work! If you don't mind, please Cc: me as I am not subscribed to the network mailing list. My work is based on v4.1-rc3. Unfortunately the VLAN support breaks on latest net-next/master (e.g. NETIF_F_HW_SWITCH_OFFLOAD is removed; .ndo_bridge_setlink used to set tag and PVID, is moved to switchdev.) Are you willing to give it a try based on v4.1-rc3 in the meantime? Otherwise, I'll send the RFC as soon as the support is functional on net-next. I already rebased my code to net-next, not for the switchdev changes but to catch the dsa changes, so net-next would be much better. I'd like to get a glance at your code, though, if that is possible. Thanks, Guenter -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DSA and underlying 802.1Q encapsulation
Hi Guenter, If yes, the dsa code may need to move the tag into the header. If we are lucky, a call to vlan_hwaccel_push_inside() might do it. Thanks, I'm currently looking into it and doing some tests, I'm coming back to you asap. Issue fixed, thanks! vlan_hwaccel_push_inside() adds additional memmove, but this approach is simpler. Do you have some vlan dsa code to share, by any chance ? That might save me some time, as I am looking into it as well. Yes, I am about the send an RFC for fully integrated 802.1q VLAN support on Marvell 88E6352 devices. Excellent, that is going to safe me a lot of work! If you don't mind, please Cc: me as I am not subscribed to the network mailing list. My work is based on v4.1-rc3. Unfortunately the VLAN support breaks on latest net-next/master (e.g. NETIF_F_HW_SWITCH_OFFLOAD is removed; .ndo_bridge_setlink used to set tag and PVID, is moved to switchdev.) Are you willing to give it a try based on v4.1-rc3 in the meantime? Otherwise, I'll send the RFC as soon as the support is functional on net-next. Thanks, -v -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DSA and underlying 802.1Q encapsulation
Hi Guenter, Interesting question. Does the underlying network device support VLAN HW acceleration (NETIF_F_HW_VLAN_CTAG_RX, NETIF_F_HW_VLAN_CTAG_TX) ? Yes, in our case, it's an IGB device. I also set the DSA slave_dev-features and slave_dev-vlan_features to master-vlan_features | NETIF_F_VLAN_FEATURES | NETIF_F_HW_SWITCH_OFFLOAD, not sure if it is good or not. If yes, the dsa code may need to move the tag into the header. If we are lucky, a call to vlan_hwaccel_push_inside() might do it. Thanks, I'm currently looking into it and doing some tests, I'm coming back to you asap. Do you have some vlan dsa code to share, by any chance ? That might save me some time, as I am looking into it as well. Yes, I am about the send an RFC for fully integrated 802.1q VLAN support on Marvell 88E6352 devices. Thanks, -v -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DSA and underlying 802.1Q encapsulation
On 05/27/2015 01:48 PM, Vivien Didelot wrote: Hi Guenter, Interesting question. Does the underlying network device support VLAN HW acceleration (NETIF_F_HW_VLAN_CTAG_RX, NETIF_F_HW_VLAN_CTAG_TX) ? Yes, in our case, it's an IGB device. I also set the DSA slave_dev-features and slave_dev-vlan_features to master-vlan_features | NETIF_F_VLAN_FEATURES | NETIF_F_HW_SWITCH_OFFLOAD, not sure if it is good or not. I have experimented with NETIF_F_HW_VLAN_CTAG_FILTER, with associated code in the switch driver, to provide vlan filtering in the switch, but so far I think I am doing something wrong. Do you have lock debugging enabled in your code ? I am getting a recursive lock warning due to a recursive call to dev_mc_sync(). I think we may have to implement lock nesting for dsa, similar to how it id done for vlan support, but I have not been able to figure out how exactly it works yet. If yes, the dsa code may need to move the tag into the header. If we are lucky, a call to vlan_hwaccel_push_inside() might do it. Thanks, I'm currently looking into it and doing some tests, I'm coming back to you asap. Do you have some vlan dsa code to share, by any chance ? That might save me some time, as I am looking into it as well. Yes, I am about the send an RFC for fully integrated 802.1q VLAN support on Marvell 88E6352 devices. Excellent, that is going to safe me a lot of work! If you don't mind, please Cc: me as I am not subscribed to the network mailing list. Thanks, Guenter -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DSA and underlying 802.1Q encapsulation
Do you have lock debugging enabled in your code ? I am getting a recursive lock warning due to a recursive call to dev_mc_sync(). I think we may have to implement lock nesting for dsa, similar to how it id done for vlan support, but I have not been able to figure out how exactly it works yet. I might be able to help, since i solve two similar problems already in DSA, one for MDIO bus, and a second one for transmit buffers. Andrew -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DSA and underlying 802.1Q encapsulation
On 05/27/2015 06:46 PM, Andrew Lunn wrote:
On Wed, May 27, 2015 at 03:51:59PM -0700, Guenter Roeck wrote:
On 05/27/2015 02:05 PM, Andrew Lunn wrote:
Do you have lock debugging enabled in your code ? I am getting a recursive
lock warning due to a recursive call to dev_mc_sync(). I think we may have
to implement lock nesting for dsa, similar to how it id done for vlan
support, but I have not been able to figure out how exactly it works yet.
I might be able to help, since i solve two similar problems already in
DSA, one for MDIO bus, and a second one for transmit buffers.
Andrew
What I did is to create a vlan interface on one of the dsa slave ports
and enabling it.
This results in a call to dev_mc_sync() on the dsa interface, which is passed
on to the real interface. dev_mc_sync() calls netif_addr_lock_nested(to),
which results in the recursive lock message.
ifconfig/2291 is trying to acquire lock:
(_xmit_ETHER/1){+.}, at: [8175b757] dev_mc_sync+0x57/0xa0
but task is already holding lock:
(_xmit_ETHER/1){+.}, at: [8175b757] dev_mc_sync+0x57/0xa0
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(_xmit_ETHER/1);
lock(_xmit_ETHER/1);
Pretty much inevitable as far as I can see.
It looks like DSA needs to implement ndo_get_lock_subclass().
We can probably copy the code from macvlan.c.
Not entirely, but I think I have an idea. I'll give it a try.
Guenter
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DSA and underlying 802.1Q encapsulation
On Wed, May 27, 2015 at 03:51:59PM -0700, Guenter Roeck wrote:
On 05/27/2015 02:05 PM, Andrew Lunn wrote:
Do you have lock debugging enabled in your code ? I am getting a recursive
lock warning due to a recursive call to dev_mc_sync(). I think we may have
to implement lock nesting for dsa, similar to how it id done for vlan
support, but I have not been able to figure out how exactly it works yet.
I might be able to help, since i solve two similar problems already in
DSA, one for MDIO bus, and a second one for transmit buffers.
Andrew
What I did is to create a vlan interface on one of the dsa slave ports
and enabling it.
This results in a call to dev_mc_sync() on the dsa interface, which is passed
on to the real interface. dev_mc_sync() calls netif_addr_lock_nested(to),
which results in the recursive lock message.
ifconfig/2291 is trying to acquire lock:
(_xmit_ETHER/1){+.}, at: [8175b757] dev_mc_sync+0x57/0xa0
but task is already holding lock:
(_xmit_ETHER/1){+.}, at: [8175b757] dev_mc_sync+0x57/0xa0
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(_xmit_ETHER/1);
lock(_xmit_ETHER/1);
Pretty much inevitable as far as I can see.
It looks like DSA needs to implement ndo_get_lock_subclass().
We can probably copy the code from macvlan.c.
Andrew
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DSA and underlying 802.1Q encapsulation
On 05/27/2015 02:05 PM, Andrew Lunn wrote:
Do you have lock debugging enabled in your code ? I am getting a recursive
lock warning due to a recursive call to dev_mc_sync(). I think we may have
to implement lock nesting for dsa, similar to how it id done for vlan
support, but I have not been able to figure out how exactly it works yet.
I might be able to help, since i solve two similar problems already in
DSA, one for MDIO bus, and a second one for transmit buffers.
Andrew
What I did is to create a vlan interface on one of the dsa slave ports
and enabling it.
This results in a call to dev_mc_sync() on the dsa interface, which is passed
on to the real interface. dev_mc_sync() calls netif_addr_lock_nested(to),
which results in the recursive lock message.
ifconfig/2291 is trying to acquire lock:
(_xmit_ETHER/1){+.}, at: [8175b757] dev_mc_sync+0x57/0xa0
but task is already holding lock:
(_xmit_ETHER/1){+.}, at: [8175b757] dev_mc_sync+0x57/0xa0
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(_xmit_ETHER/1);
lock(_xmit_ETHER/1);
Pretty much inevitable as far as I can see.
Tentative solution would be to implement nesting as in the 802.1q code,
ie similar to vlan_dev_get_lock_subclass() and
vlan-nest_level = dev_get_nest_level(real_dev, is_vlan_dev) + 1;
but I am not sure on how to set nest_level.
Can we call dev_get_nest_level() with the Ethernet (cpu) interface as
parameter and add 1 ? If so, what should the second parameter evaluate ?
Or is there a better solution ?
Thanks,
Guenter
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DSA and underlying 802.1Q encapsulation
On Tue, May 26, 2015 at 06:29:57PM -0400, Vivien Didelot wrote: Hi, I'm doing tests with VLAN support in DSA and I noticed that the EDSA frame is prepended with a 802.1q header once queued to the underlying network device, in net/dsa/tag_edsa.c: skb-dev = p-parent-dst-master_netdev; dev_queue_xmit(skb); This issue can be observed with the following dump: curl -s http://ix.io/iIv | tcpdump -en -r - I suspect that the DSA code must clear some VLAN flags in the skb structure, in order to prevent the additional encapsulation by the lower level. Does this make sense? Hi Vivien, Interesting question. Does the underlying network device support VLAN HW acceleration (NETIF_F_HW_VLAN_CTAG_RX, NETIF_F_HW_VLAN_CTAG_TX) ? If yes, the dsa code may need to move the tag into the header. If we are lucky, a call to vlan_hwaccel_push_inside() might do it. Do you have some vlan dsa code to share, by any chance ? That might save me some time, as I am looking into it as well. Thanks, Guenter -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
