From: MD Danish Anwar <danishanwar@ti.com>
To: Paolo Abeni <pabeni@redhat.com>, <geliang@kernel.org>,
<liuhangbin@gmail.com>, <dan.carpenter@linaro.org>,
<jiri@resnulli.us>, <n.zhandarovich@fintech.ru>,
<aleksander.lobakin@intel.com>, <lukma@denx.de>,
<horms@kernel.org>, <jan.kiszka@siemens.com>,
<diogo.ivo@siemens.com>, <shuah@kernel.org>, <kuba@kernel.org>,
<edumazet@google.com>, <davem@davemloft.net>,
<andrew+netdev@lunn.ch>
Cc: <linux-kselftest@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<netdev@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org>,
<srk@ti.com>, Vignesh Raghavendra <vigneshr@ti.com>,
Roger Quadros <rogerq@kernel.org>, <m-malladi@ti.com>
Subject: Re: [PATCH net-next v2 2/4] net: hsr: Add VLAN CTAG filter support
Date: Mon, 4 Nov 2024 16:50:47 +0530 [thread overview]
Message-ID: <0e661e6a-6057-4a16-bc41-b96cd18e8fe7@ti.com> (raw)
In-Reply-To: <96516e40-5b1b-4bce-a041-7618c03c5de3@redhat.com>
Hi Paolo,
On 31/10/24 8:07 pm, Paolo Abeni wrote:
>
>
> On 10/24/24 12:30, MD Danish Anwar wrote:
>> From: Murali Karicheri <m-karicheri2@ti.com>
>>
>> This patch adds support for VLAN ctag based filtering at slave devices.
>> The slave ethernet device may be capable of filtering ethernet packets
>> based on VLAN ID. This requires that when the VLAN interface is created
>> over an HSR/PRP interface, it passes the VID information to the
>> associated slave ethernet devices so that it updates the hardware
>> filters to filter ethernet frames based on VID. This patch adds the
>> required functions to propagate the vid information to the slave
>> devices.
>>
>> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
>> Signed-off-by: MD Danish Anwar <danishanwar@ti.com>
>> ---
>> net/hsr/hsr_device.c | 71 +++++++++++++++++++++++++++++++++++++++++++-
>> 1 file changed, 70 insertions(+), 1 deletion(-)
>>
>> diff --git a/net/hsr/hsr_device.c b/net/hsr/hsr_device.c
>> index 0ca47ebb01d3..ff586bdc2bde 100644
>> --- a/net/hsr/hsr_device.c
>> +++ b/net/hsr/hsr_device.c
>> @@ -515,6 +515,68 @@ static void hsr_change_rx_flags(struct net_device *dev, int change)
>> }
>> }
>>
>> +static int hsr_ndo_vlan_rx_add_vid(struct net_device *dev,
>> + __be16 proto, u16 vid)
>> +{
>> + struct hsr_port *port;
>> + struct hsr_priv *hsr;
>> + int ret = 0;
>> +
>> + hsr = netdev_priv(dev);
>> +
>> + hsr_for_each_port(hsr, port) {
>> + if (port->type == HSR_PT_MASTER)
>> + continue;
>
> If the desired behavior is to ignore INTERLINK port, I think you should
> explicitly skip them here, otherwise you will end-up in a
> nondeterministic state.
>
Sure, I will change this to
hsr_for_each_port(hsr, port) {
if (port->type == HSR_PT_MASTER ||
port->type = HSR_PT_INTERLINK)
continue;
>> + ret = vlan_vid_add(port->dev, proto, vid);
>> + switch (port->type) {
>> + case HSR_PT_SLAVE_A:
>> + if (ret) {
>> + netdev_err(dev, "add vid failed for Slave-A\n");
>> + return ret;
>> + }
>> + break;
>> +
>> + case HSR_PT_SLAVE_B:
>> + if (ret) {
>> + /* clean up Slave-A */
>> + netdev_err(dev, "add vid failed for Slave-B\n");
>> + vlan_vid_del(port->dev, proto, vid);
>
> This code relies on a specific port_list order - which is actually
> respected at list creation time. Still such assumption looks fragile and
> may lead to long term bugs.
>
Agreed. The code is expecting HSR_PT_SLAVE_A to come first and add vid
for it. Then vid is added for HSR_PT_SLAVE_B. if vlan_vid_add fails for
HSR_PT_SLAVE_B, vid is deleted for HSR_PT_SLAVE_A before returning.
> I think would be better to refactor the above loop handling arbitrary
> HSR_PT_SLAVE_A, HSR_PT_SLAVE_B order. Guestimate is that the complexity
> will not increase measurably.
>
I understand this will be better. But how would I figure out which port
came first.
The current implementation is to add vid for first port. If it fails it
returns. If it passes it adds vid for second port. If it fails it clears
vid of first port and returns. If it passes function returns 0.
Now how do I keep this behavior and also handle ports arbitrary. If the
same order is not guaranteed to be preserved, how would I know which
port came first so that it can be deleted if second port fails?
One idea I have is to keep two boolean flags is_slave_a_added,
is_slave_b_added. And based on these flags we can determine if cleanup
is needed or not.
The add function will then look like this,
static int hsr_ndo_vlan_rx_add_vid(struct net_device *dev,
__be16 proto, u16 vid)
{
bool is_slave_a_added, is_slave_b_added;
struct hsr_port *port;
struct hsr_priv *hsr;
int ret = 0;
hsr = netdev_priv(dev);
hsr_for_each_port(hsr, port) {
if (port->type == HSR_PT_MASTER ||
port->type = HSR_PT_INTERLINK)
continue;
ret = vlan_vid_add(port->dev, proto, vid);
switch (port->type) {
case HSR_PT_SLAVE_A:
if (ret) {
/* clean up Slave-B */
netdev_err(dev, "add vid failed for Slave-A\n");
if (is_slave_b_added)
vlan_vid_del(port->dev, proto, vid);
return ret;
} else {
is_slave_a_added = true;
}
break;
case HSR_PT_SLAVE_B:
if (ret) {
/* clean up Slave-A */
netdev_err(dev, "add vid failed for Slave-B\n");
if (is_slave_a_added)
vlan_vid_del(port->dev, proto, vid);
return ret;
} else {
is_slave_b_added = true;
}
break;
default:
break;
}
}
return 0;
}
Let me know if this is OK. Or if you have some other method to handle
the ports arbitrary.
>> + return ret;
>> + }
>> + break;
>> + default:
>> + break;
>> + }
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static int hsr_ndo_vlan_rx_kill_vid(struct net_device *dev,
>> + __be16 proto, u16 vid)
>> +{
>> + struct hsr_port *port;
>> + struct hsr_priv *hsr;
>> +
>> + hsr = netdev_priv(dev);
>> +
>> + hsr_for_each_port(hsr, port) {
>> + if (port->type == HSR_PT_MASTER)
>> + continue;
>
> I think it would be more consistent just removing the above statement...
>
Sure. I'll do it.
>> + switch (port->type) {
>> + case HSR_PT_SLAVE_A:
>> + case HSR_PT_SLAVE_B:
>> + vlan_vid_del(port->dev, proto, vid);
>> + break;
>> + default:> + break;
>
> ... MASTER and INTERLINK port will be ignored anyway.
>
Sure.
>> + }
>> + }
>> +
>> + return 0;
>> +}
>> +
>> static const struct net_device_ops hsr_device_ops = {
>> .ndo_change_mtu = hsr_dev_change_mtu,
>> .ndo_open = hsr_dev_open,
>
> Cheers,
>
> Paolo
>
--
Thanks and Regards,
Danish
next prev parent reply other threads:[~2024-11-04 11:21 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-24 10:30 [PATCH net-next v2 0/4] Introduce VLAN support in HSR MD Danish Anwar
2024-10-24 10:30 ` [PATCH net-next v2 1/4] net: hsr: Add VLAN support MD Danish Anwar
2024-10-24 10:30 ` [PATCH net-next v2 2/4] net: hsr: Add VLAN CTAG filter support MD Danish Anwar
2024-10-24 13:36 ` Vadim Fedorenko
2024-10-24 15:10 ` Anwar, Md Danish
2024-10-31 14:37 ` Paolo Abeni
2024-11-04 11:20 ` MD Danish Anwar [this message]
2024-10-24 10:30 ` [PATCH net-next v2 3/4] net: ti: icssg-prueth: Add VLAN support for HSR mode MD Danish Anwar
2024-10-24 10:30 ` [PATCH net-next v2 4/4] selftests: hsr: Add test for VLAN MD Danish Anwar
2024-10-31 14:41 ` Paolo Abeni
2024-11-05 11:14 ` MD Danish Anwar
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=0e661e6a-6057-4a16-bc41-b96cd18e8fe7@ti.com \
--to=danishanwar@ti.com \
--cc=aleksander.lobakin@intel.com \
--cc=andrew+netdev@lunn.ch \
--cc=dan.carpenter@linaro.org \
--cc=davem@davemloft.net \
--cc=diogo.ivo@siemens.com \
--cc=edumazet@google.com \
--cc=geliang@kernel.org \
--cc=horms@kernel.org \
--cc=jan.kiszka@siemens.com \
--cc=jiri@resnulli.us \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=liuhangbin@gmail.com \
--cc=lukma@denx.de \
--cc=m-malladi@ti.com \
--cc=n.zhandarovich@fintech.ru \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=rogerq@kernel.org \
--cc=shuah@kernel.org \
--cc=srk@ti.com \
--cc=vigneshr@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