Message ID | 20230829121132.414335-2-lukma@denx.de (mailing list archive) |
---|---|
State | Superseded |
Delegated to: | Netdev Maintainers |
Headers | show |
Series | net: dsa: hsr: Enable HSR HW offloading for KSZ9477 | expand |
Context | Check | Description |
---|---|---|
netdev/tree_selection | success | Guessing tree name failed - patch did not apply |
On Tue, 2023-08-29 at 14:11 +0200, Lukasz Majewski wrote: > Information about HSR aware ports in a DSA switch can be helpful when > one needs tags to be adjusted before the HSR frame is sent. > > For example - with ksz9477 switch - the TAG needs to be adjusted to have > both HSR ports marked in tag to allow execution of HW based frame > duplication. > > Signed-off-by: Lukasz Majewski <lukma@denx.de> > --- > include/net/dsa.h | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/include/net/dsa.h b/include/net/dsa.h > index d309ee7ed04b..15274afc42bb 100644 > --- a/include/net/dsa.h > +++ b/include/net/dsa.h > @@ -470,6 +470,9 @@ struct dsa_switch { > /* Number of switch port queues */ > unsigned int num_tx_queues; > > + /* Bitmask indicating ports supporting HSR */ > + u16 hsr_ports; > + > /* Drivers that benefit from having an ID associated with each > * offloaded LAG should set this to the maximum number of > * supported IDs. DSA will then maintain a mapping of _at Out of sheer ignorance, I think this new field does not belong to dsa_switch, at least not in this form. AFAICS there is no current hard limitation on the number of ports a DSA switch can handle at the API level, and this will introduce an hard one. I think you are better off keeping this field in the KSZ-specific struct. If you really want to keep it here you should remove the above limitation somehow (possibly a query op to check if a given port is HSR aware???) In any case this series looks like net-next material, does not apply correctly to net-next and net-next is currently closed. You can share a new version as RFC or wait for net-next to re-open in ~2w. Cheers, Paolo
Hi Paolo, > On Tue, 2023-08-29 at 14:11 +0200, Lukasz Majewski wrote: > > Information about HSR aware ports in a DSA switch can be helpful > > when one needs tags to be adjusted before the HSR frame is sent. > > > > For example - with ksz9477 switch - the TAG needs to be adjusted to > > have both HSR ports marked in tag to allow execution of HW based > > frame duplication. > > > > Signed-off-by: Lukasz Majewski <lukma@denx.de> > > --- > > include/net/dsa.h | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/include/net/dsa.h b/include/net/dsa.h > > index d309ee7ed04b..15274afc42bb 100644 > > --- a/include/net/dsa.h > > +++ b/include/net/dsa.h > > @@ -470,6 +470,9 @@ struct dsa_switch { > > /* Number of switch port queues */ > > unsigned int num_tx_queues; > > > > + /* Bitmask indicating ports supporting HSR */ > > + u16 hsr_ports; > > + > > /* Drivers that benefit from having an ID associated with > > each > > * offloaded LAG should set this to the maximum number of > > * supported IDs. DSA will then maintain a mapping of _at > > Out of sheer ignorance, I think this new field does not belong to > dsa_switch, at least not in this form. AFAICS there is no current hard > limitation on the number of ports a DSA switch can handle at the API > level, and this will introduce an hard one. > > I think you are better off keeping this field in the KSZ-specific > struct. That was mine first idea - to move it to struct ksz_device from ./drivers/net/dsa/ksz_common.h However, this file and this struct is not easily accessible from net/dsa/tag_ksz.c One idea was to use an exported function - e.g. ksz_get_hsr_ports() and in it I would read the hsr_ports member ? Another option would be to loop through all switch ports with hsr_for_each_port(), but this would affect overall network performance. > If you really want to keep it here you should remove the above > limitation somehow (possibly a query op to check if a given port is > HSR aware???) I will use the idea of exported helper function to get HSR members ports. > > In any case this series looks like net-next material, does not apply > correctly to net-next and net-next is currently closed. You can share > a new version as RFC or wait for net-next to re-open in ~2w. > I will prepare v2 and then adjust it to net-next when required. > Cheers, > > Paolo > Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Erika Unter HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
diff --git a/include/net/dsa.h b/include/net/dsa.h index d309ee7ed04b..15274afc42bb 100644 --- a/include/net/dsa.h +++ b/include/net/dsa.h @@ -470,6 +470,9 @@ struct dsa_switch { /* Number of switch port queues */ unsigned int num_tx_queues; + /* Bitmask indicating ports supporting HSR */ + u16 hsr_ports; + /* Drivers that benefit from having an ID associated with each * offloaded LAG should set this to the maximum number of * supported IDs. DSA will then maintain a mapping of _at
Information about HSR aware ports in a DSA switch can be helpful when one needs tags to be adjusted before the HSR frame is sent. For example - with ksz9477 switch - the TAG needs to be adjusted to have both HSR ports marked in tag to allow execution of HW based frame duplication. Signed-off-by: Lukasz Majewski <lukma@denx.de> --- include/net/dsa.h | 3 +++ 1 file changed, 3 insertions(+)