Messages in this thread | | | From | Loic Poulain <> | Date | Wed, 15 Dec 2021 10:29:48 +0100 | Subject | Re: [PATCH] Add Multiple TX/RX Queues Support for WWAN Network Device |
| |
Hi Xiayu, Sergey,
> > > > As for the default queues number selection it seems better to > > > > implement the RTNL .get_num_rx_queues callback in the WWAN core > > > > and > > > > call optional driver specific callback through it. Something like > > > > this: > > > > > > > > static unsigned int wwan_rtnl_get_num_tx_queues(struct nlattr > > > > *tb[]) > > > > { > > > > const char *devname = nla_data(tb[IFLA_PARENT_DEV_NAME]); > > > > struct wwan_device *wwandev = wwan_dev_get_by_name(devname); > > > > > > > > return wwandev && wwandev->ops && wwandev->ops- > > > > >get_num_tx_queues > > > > ? > > > > wwandev->ops->get_num_tx_queues() : 1; > > > > } > > > > > > > > static struct rtnl_link_ops wwan_rtnl_link_ops __read_mostly = { > > > > ... > > > > .get_num_tx_queues = wwan_rtnl_get_num_tx_queues, > > > > }; > > > > > > > > This way the default queues number selection will be implemented > > > > in a > > > > less surprising way. > > > > > > > > But to be able to implement this we need to modify the RTNL ops > > > > .get_num_tx_queues/.get_num_rx_queues callback definitions to > > > > make > > > > them able to accept the RTM_NEWLINK message attributes. This is > > > > not > > > > difficult since the callbacks are implemented only by a few > > > > virtual > > > > devices, but can be assumed too intrusive to implement a one > > > > feature > > > > for a single subsystem.
I agree with this solution. The wwan core can forward get_num_tx_queues to per wwan driver callbacks or simply rely on a 'default_tx_queues' field in ops struct. As said previously, you need a user for this change in the same series.
Regards, Loic
| |