[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9c451d25fb36bc82e602bb93e384b262be743fbf.camel@redhat.com>
Date: Fri, 09 Jul 2021 16:38:02 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Toke Høiland-Jørgensen <toke@...hat.com>,
netdev@...r.kernel.org
Cc: "David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>
Subject: Re: [RFC PATCH 1/3] veth: implement support for set_channel ethtool
op
On Fri, 2021-07-09 at 12:49 +0200, Paolo Abeni wrote:
> On Fri, 2021-07-09 at 12:15 +0200, Toke Høiland-Jørgensen wrote:
> > > + if (netif_running(dev))
> > > + veth_close(dev);
> > > +
> > > + priv->num_tx_queues = ch->tx_count;
> > > + priv->num_rx_queues = ch->rx_count;
> >
> > Why can't just you use netif_set_real_num_*_queues() here directly (and
> > get rid of the priv members as above)?
>
> Uhm... I haven't thought about it. Let me try ;)
Here there is a possible problem: if the latter
netif_set_real_num_*_queues() fails, we should not change the current
configuration, so we should revert the
first netif_set_real_num_*_queues() change.
Even that additional revert operation could fail. If/when that happen
set_channel() will leave the device in a different state from both the
old one and the new one, possibly with an XDP-incompatible number of
queues.
Keeping the netif_set_real_num_*_queues() calls in veth_open() avoid
the above issue: if the queue creation is problematic, the device will
stay down.
I think the additional fields are worthy, WDYT?
Cheers,
Paolo
Powered by blists - more mailing lists