From: Petr Machata <petrm@nvidia.com>
To: <Daniel.Machon@microchip.com>
Cc: <petrm@nvidia.com>, <netdev@vger.kernel.org>,
<davem@davemloft.net>, <edumazet@google.com>, <kuba@kernel.org>,
<pabeni@redhat.com>, <Lars.Povlsen@microchip.com>,
<Steen.Hegelund@microchip.com>, <UNGLinuxDriver@microchip.com>,
<joe@perches.com>, <error27@gmail.com>,
<Horatiu.Vultur@microchip.com>, <Julia.Lawall@inria.fr>,
<vladimir.oltean@nxp.com>, <maxime.chevallier@bootlin.com>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH net-next v2 3/6] net: dcb: add new rewrite table
Date: Wed, 18 Jan 2023 16:20:31 +0100 [thread overview]
Message-ID: <874jsnalyv.fsf@nvidia.com> (raw)
In-Reply-To: <Y8f4i2ablWnNO9Op@DEN-LT-70577>
<Daniel.Machon@microchip.com> writes:
>> > + rewr = nla_nest_start_noflag(skb, DCB_ATTR_DCB_REWR_TABLE);
>> > + if (!rewr)
>> > + return -EMSGSIZE;
>>
>> This being new code, don't use _noflag please.
>
> Ack.
>
>>
>> > +
>> > + spin_lock_bh(&dcb_lock);
>> > + list_for_each_entry(itr, &dcb_rewr_list, list) {
>> > + if (itr->ifindex == netdev->ifindex) {
>> > + enum ieee_attrs_app type =
>> > + dcbnl_app_attr_type_get(itr->app.selector);
>> > + err = nla_put(skb, type, sizeof(itr->app), &itr->app);
>> > + if (err) {
>> > + spin_unlock_bh(&dcb_lock);
>>
>> This should cancel the nest started above.
>
> Yes, it should.
>
>>
>> I wonder if it would be cleaner in a separate function, so that there
>> can be a dedicated clean-up block to goto.
>
> Well yes. That would make sense if the function were reused for both APP
> and rewr.
I meant purely for to make the cleanup clear. The function would be
approximately:
static int dcbnl_ieee_fill_rewr(struct sk_buff *skb, struct net_device *netdev)
{
struct dcb_app_type *itr;
struct nlattr *rewr;
int err;
rewr = nla_nest_start_noflag(skb, DCB_ATTR_DCB_REWR_TABLE);
if (!rewr)
return -EMSGSIZE;
spin_lock_bh(&dcb_lock);
list_for_each_entry(itr, &dcb_rewr_list, list) {
if (itr->ifindex == netdev->ifindex) {
enum ieee_attrs_app type =
dcbnl_app_attr_type_get(itr->app.selector);
err = nla_put(skb, type, sizeof(itr->app), &itr->app);
if (err)
goto err_out;
}
}
spin_unlock_bh(&dcb_lock);
nla_nest_end(skb, rewr);
return 0;
err_out:
spin_unlock_bh(&dcb_lock);
nla_nest_cancel(skb, rewr);
return err;
}
Which uses an idiomatic style with the cleanup block at the end, instead
of stashing the individual cleanups before the return statement. I find
it easier to reason about.
But it's not a big deal. Your thing is readable just fine.
> Though in the APP equivalent code, nla_nest_start_noflag is used, and
> dcbnl_ops->getdcbx() is called. Is there any userspace side-effect of
> using nla_nest_start for APP too?
Yeah, the clients would be looking for code DCB_ATTR_IEEE_APP_TABLE, but
would get DCB_ATTR_IEEE_APP_TABLE | NLA_F_NESTED, and get confused.
For reuse between APP_TABLE and REWR_TABLE, you could just always call
_noflag in the helper, and pass the actual attribute in an argument.
Then the argument would be either DCB_ATTR_DCB_REWR_TABLE | NLA_F_NESTED,
or just plain DCB_ATTR_IEEE_APP_TABLE.
But that makes the code less clear, and I don't feel it brings much.
> dcbnl_ops->getdcbx() would then be left outside of the shared function.
> Does that call even have to hold the dcb_lock? Not as far as I can tell.
>
> something like:
>
> err = dcbnl_app_table_get(ndev, skb, &dcb_app_list,
> DCB_ATTR_IEEE_APP_TABLE);
> if (err)
> return -EMSGSIZE;
>
> err = dcbnl_app_table_get(ndev, skb, &dcb_rewr_list,
> DCB_ATTR_DCB_REWR_TABLE);
> if (err)
> return -EMSGSIZE;
>
> if (netdev->dcbnl_ops->getdcbx)
> dcbx = netdev->dcbnl_ops->getdcbx(netdev); <-- without lock held
> else
> dcbx = -EOPNOTSUPP;
>
> Let me hear your thoughts.
Yeah, and the dcbx stuff is the added wrinkle.
Dunno, I'd not force it. This redundancy is not great, but the code is
small and easy to understand, so I find it's not an issue.
next prev parent reply other threads:[~2023-01-18 15:42 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-16 14:48 [PATCH net-next v2 0/6] Introduce new DCB rewrite table Daniel Machon
2023-01-16 14:48 ` [PATCH net-next v2 1/6] net: dcb: modify dcb_app_add to take list_head ptr as parameter Daniel Machon
2023-01-18 11:02 ` Petr Machata
2023-01-16 14:48 ` [PATCH net-next v2 2/6] net: dcb: add new common function for set/del of app/rewr entries Daniel Machon
2023-01-18 10:26 ` Petr Machata
2023-01-18 11:03 ` Petr Machata
2023-01-18 13:56 ` Daniel.Machon
2023-01-18 15:42 ` Petr Machata
2023-01-16 14:48 ` [PATCH net-next v2 3/6] net: dcb: add new rewrite table Daniel Machon
2023-01-18 10:54 ` Petr Machata
2023-01-18 13:47 ` Daniel.Machon
2023-01-18 15:20 ` Petr Machata [this message]
2023-01-18 15:07 ` Dan Carpenter
2023-01-18 15:11 ` Dan Carpenter
2023-01-19 9:38 ` Petr Machata
2023-01-16 14:48 ` [PATCH net-next v2 4/6] net: dcb: add helper functions to retrieve PCP and DSCP rewrite maps Daniel Machon
2023-01-18 11:01 ` Petr Machata
2023-01-16 14:48 ` [PATCH net-next v2 5/6] net: microchip: sparx5: add support for PCP rewrite Daniel Machon
2023-01-16 14:48 ` [PATCH net-next v2 6/6] net: microchip: sparx5: add support for DSCP rewrite Daniel Machon
2023-01-18 11:00 ` [PATCH net-next v2 0/6] Introduce new DCB rewrite table Simon Horman
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=874jsnalyv.fsf@nvidia.com \
--to=petrm@nvidia.com \
--cc=Daniel.Machon@microchip.com \
--cc=Horatiu.Vultur@microchip.com \
--cc=Julia.Lawall@inria.fr \
--cc=Lars.Povlsen@microchip.com \
--cc=Steen.Hegelund@microchip.com \
--cc=UNGLinuxDriver@microchip.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=error27@gmail.com \
--cc=joe@perches.com \
--cc=kuba@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maxime.chevallier@bootlin.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=vladimir.oltean@nxp.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;
as well as URLs for NNTP newsgroup(s).