[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230727054300-mutt-send-email-mst@kernel.org>
Date: Thu, 27 Jul 2023 05:46:45 -0400
From: "Michael S. Tsirkin" <mst@...hat.com>
To: Jason Wang <jasowang@...hat.com>
Cc: Maxime Coquelin <maxime.coquelin@...hat.com>,
Shannon Nelson <shannon.nelson@....com>, xuanzhuo@...ux.alibaba.com,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
virtualization@...ts.linux-foundation.org, edumazet@...gle.com,
kuba@...nel.org, pabeni@...hat.com, davem@...emloft.net
Subject: Re: [PATCH net-next v4 2/2] virtio-net: add cond_resched() to the
command waiting loop
On Thu, Jul 27, 2023 at 04:59:33PM +0800, Jason Wang wrote:
> > They really shouldn't - any NIC that takes forever to
> > program will create issues in the networking stack.
>
> Unfortunately, it's not rare as the device/cvq could be implemented
> via firmware or software.
Currently that mean one either has sane firmware with a scheduler that
can meet deadlines, or loses ability to report errors back.
> > But if they do they can always set this flag too.
>
> This may have false negatives and may confuse the management.
>
> Maybe we can extend the networking core to allow some device specific
> configurations to be done with device specific lock without rtnl. For
> example, split the set_channels to
>
> pre_set_channels
> set_channels
> post_set_channels
>
> The device specific part could be done in pre and post without a rtnl lock?
>
> Thanks
Would the benefit be that errors can be reported to userspace then?
Then maybe. I think you will have to show how this works for at least
one card besides virtio.
--
MST
Powered by blists - more mailing lists