[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAF=yD-K4mrqY-YjsWL1JkYhqBOSciRTyvMtTv5CQU7Uq6GeypA@mail.gmail.com>
Date: Wed, 12 Sep 2018 14:07:25 -0400
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: f.fainelli@...il.com
Cc: Network Development <netdev@...r.kernel.org>,
David Miller <davem@...emloft.net>, caleb.raitto@...il.com,
Jason Wang <jasowang@...hat.com>,
"Michael S. Tsirkin" <mst@...hat.com>,
"Jon Olson (Google Drive)" <jonolson@...gle.com>,
Willem de Bruijn <willemb@...gle.com>
Subject: Re: [PATCH net-next] virtio_net: ethtool tx napi configuration
On Wed, Sep 12, 2018 at 1:42 PM Florian Fainelli <f.fainelli@...il.com> wrote:
>
>
>
> On 9/9/2018 3:44 PM, Willem de Bruijn wrote:
> > From: Willem de Bruijn <willemb@...gle.com>
> >
> > Implement ethtool .set_coalesce (-C) and .get_coalesce (-c) handlers.
> > Interrupt moderation is currently not supported, so these accept and
> > display the default settings of 0 usec and 1 frame.
> >
> > Toggle tx napi through a bit in tx-frames. So as to not interfere
> > with possible future interrupt moderation, use bit 10, well outside
> > the reasonable range of real interrupt moderation values.
> >
> > Changes are not atomic. The tx IRQ, napi BH and transmit path must
> > be quiesced when switching modes. Only allow changing this setting
> > when the device is down.
>
> Humm, would not a private ethtool flag to switch TX NAPI on/off be more
> appropriate rather than use the coalescing configuration API here?
What do you mean by private ethtool flag? A new field in ethtool
--features (-k)?
Configurable napi-tx is not a common feature across devices. We really
want virtio-net to also just convert to napi-tx as default, but need a
way to gradually convert with application opt-out if some workloads
see regressions. There is prior art in interpreting coalesce values as
more than a direct mapping to usec. The e1000 is one example.
Powered by blists - more mailing lists