[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y48ERxYICkG9lQc1@unreal>
Date: Tue, 6 Dec 2022 10:58:47 +0200
From: Leon Romanovsky <leon@...nel.org>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Veerasenareddy Burru <vburru@...vell.com>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Paolo Abeni <pabeni@...hat.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Liron Himi <lironh@...vell.com>,
Abhijit Ayarekar <aayarekar@...vell.com>,
Sathesh B Edara <sedara@...vell.com>,
Satananda Burla <sburla@...vell.com>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>
Subject: Re: [EXT] Re: [PATCH net-next v2 2/9] octeon_ep: poll for control
messages
On Mon, Dec 05, 2022 at 04:16:26PM -0800, Jakub Kicinski wrote:
> On Mon, 5 Dec 2022 10:10:34 +0200 Leon Romanovsky wrote:
> > > These messages include periodic keep alive (heartbeat) messages
> > > from FW and control messages from VFs. Every PF will be listening
> > > for its own control messages.
> >
> > @netdev, as I said, I don't know if it is valid behaviour in netdev.
> > Can you please comment?
>
> Polling for control messages every 100ms? Sure.
>
> You say "valid in netdev" so perhaps you can educate us where/why it
> would not be?
It doesn't seem right to me that idle device burns CPU cycles, while it
supports interrupts. If it needs "listen to FW", it will be much nicer to
install interrupts immediately and don't wait for netdev.
Thanks
Powered by blists - more mailing lists