On Mon, Mar 6, 2017 at 2:33 PM, Michael S. Tsirkin <m...@redhat.com> wrote: > On Mon, Mar 06, 2017 at 10:55:22AM -0800, David Miller wrote: >> From: Willem de Bruijn <willemdebruijn.ker...@gmail.com> >> Date: Mon, 6 Mar 2017 12:50:19 -0500 >> >> >>> 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. > > This seems to be more or less what this driver does already. > So I suspect it can just ignore the weight.
Okay. Then we still need a boolean to toggle tx napi until we're sure that the old path can be deprecated.
