Thread (17 messages) read the whole thread 17 messages, 4 authors, 2017-03-08

Re: [PATCH net-next RFC 2/4] virtio-net: transmit napi

From: David Miller <davem@davemloft.net>
Date: 2017-03-06 19:04:41

From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: Mon, 6 Mar 2017 12:50:19 -0500
quoted
quoted
  drivers/net/virtio_net.c | 73
++++++++++++++++++++++++++++++++++++++++--------
  1 file changed, 61 insertions(+), 12 deletions(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 8c21e9a4adc7..9a9031640179 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -33,6 +33,8 @@
  static int napi_weight = NAPI_POLL_WEIGHT;
  module_param(napi_weight, int, 0444);
  +static int napi_tx_weight = NAPI_POLL_WEIGHT;
+

Maybe we should use module_param for this? Or in the future, use
tx-frames-irq for a per-device configuration.
This option should eventually just go away, and napi tx become the
standard mode.

In the short term, while we evaluate it on varied workloads, a
module_param sounds good to me. In general that is frowned
upon, as it leads to different configuration interfaces for each
device driver. But that should not be a concern in this limited
case.
In any event, do we really need a TX weight at all?

I guess you tried this, but why doesn't it not work to just do
all TX work unconditionally in a NAPI poll pass?  This is how
we encourage all NIC drivers to handle this.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help