From: Vladimir Oltean <olteanv@gmail.com>
To: Tobias Waldekranz <tobias@waldekranz.com>
Cc: davem@davemloft.net, kuba@kernel.org, andrew@lunn.ch,
vivien.didelot@gmail.com, f.fainelli@gmail.com,
j.vosburgh@gmail.com, vfalico@gmail.com, andy@greyhouse.net,
netdev@vger.kernel.org
Subject: Re: [PATCH v4 net-next 3/5] net: dsa: Link aggregation support
Date: Thu, 17 Dec 2020 20:31:50 +0200 [thread overview]
Message-ID: <20201217183150.utyeibdh7too5rmb@skbuf> (raw)
In-Reply-To: <87k0thbjhl.fsf@waldekranz.com>
On Wed, Dec 16, 2020 at 09:09:58PM +0100, Tobias Waldekranz wrote:
> On Wed, Dec 16, 2020 at 20:44, Vladimir Oltean <olteanv@gmail.com> wrote:
> > On Wed, Dec 16, 2020 at 05:00:54PM +0100, Tobias Waldekranz wrote:
> >> diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c
> >> index 183003e45762..deee4c0ecb31 100644
> >> --- a/net/dsa/dsa2.c
> >> +++ b/net/dsa/dsa2.c
> >> @@ -21,6 +21,46 @@
> >> static DEFINE_MUTEX(dsa2_mutex);
> >> LIST_HEAD(dsa_tree_list);
> >>
> >> +void dsa_lag_map(struct dsa_switch_tree *dst, struct net_device *lag)
> >
> > Maybe a small comment here and in dsa_lag_unmap, describing what they're
> > for? They look a bit bland. Just a few words about the linear array will
> > suffice.
>
> Not sure I understand why these two are "bland" whereas dsa_switch_find
> just below it is not. But sure, I will add a comment. You want a block
> comment before each function?
What I meant is that if you're just a casual reader carrying on with
your day and you see a function called dsa_switch_find, you have a vague
idea what it does just by reading the headline - it finds a DSA switch.
Whereas dsa_lag_map, I don't know, just doesn't speak to me, it's a very
uneventful name with a very uneventful implementation. If we hadn't had
the long discussion in the previous version about the linear array, I
would have honestly had to ask you what's the purpose of "mapping" and
"unmapping" a LAG. So I expect many of the readers ask themselves the
same thing, especially since the comments say that some drivers don't
use it.
I guess this would look more dynamic for me:
/* Helpers to add and remove a LAG net_device from this switch tree's
* mapping towards a linear ID. These will do nothing for drivers which
* don't populate ds->num_lag_ids, and therefore don't need the mapping.
*/
void dsa_lag_map(struct dsa_switch_tree *dst, struct net_device *lag)
{
unsigned int id;
if (dsa_lag_id(dst, lag) >= 0)
/* Already mapped */
return;
for (id = 0; id < dst->lags_len; id++) {
if (!dsa_lag_dev(dst, id)) {
dst->lags[id] = lag;
return;
}
}
/* No IDs left, which is OK. Calling dsa_lag_id will return an
* error when this device joins a LAG. The driver can then
* return -EOPNOTSUPP back to DSA, which will fall back to a
* software LAG.
*/
}
void dsa_lag_unmap(struct dsa_switch_tree *dst, struct net_device *lag)
{
struct dsa_port *dp;
unsigned int id;
dsa_lag_foreach_port(dp, dst, lag)
/* There are remaining users of this mapping */
return;
dsa_lags_foreach_id(id, dst) {
if (dsa_lag_dev(dst, id) == lag) {
dst->lags[id] = NULL;
break;
}
}
}
next prev parent reply other threads:[~2020-12-17 18:32 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-16 16:00 [PATCH v4 net-next 0/5] net: dsa: Link aggregation support Tobias Waldekranz
2020-12-16 16:00 ` [PATCH v4 net-next 1/5] net: bonding: Notify ports about their initial state Tobias Waldekranz
2020-12-16 16:28 ` Vladimir Oltean
2020-12-16 16:00 ` [PATCH v4 net-next 2/5] net: dsa: Don't offload port attributes on standalone ports Tobias Waldekranz
2020-12-16 16:27 ` Vladimir Oltean
2020-12-16 19:32 ` Tobias Waldekranz
2020-12-16 16:00 ` [PATCH v4 net-next 3/5] net: dsa: Link aggregation support Tobias Waldekranz
2020-12-16 16:22 ` Vladimir Oltean
2020-12-16 19:47 ` Tobias Waldekranz
2020-12-16 18:02 ` Vladimir Oltean
2020-12-16 19:49 ` Tobias Waldekranz
2020-12-16 18:44 ` Vladimir Oltean
2020-12-16 20:09 ` Tobias Waldekranz
2020-12-17 18:31 ` Vladimir Oltean [this message]
2020-12-16 16:00 ` [PATCH v4 net-next 4/5] net: dsa: mv88e6xxx: " Tobias Waldekranz
2020-12-16 19:04 ` Vladimir Oltean
2020-12-16 20:21 ` Tobias Waldekranz
2020-12-16 16:00 ` [PATCH v4 net-next 5/5] net: dsa: tag_dsa: Support reception of packets from LAG devices Tobias Waldekranz
2020-12-16 19:14 ` Vladimir Oltean
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=20201217183150.utyeibdh7too5rmb@skbuf \
--to=olteanv@gmail.com \
--cc=andrew@lunn.ch \
--cc=andy@greyhouse.net \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=j.vosburgh@gmail.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=tobias@waldekranz.com \
--cc=vfalico@gmail.com \
--cc=vivien.didelot@gmail.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