Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 6 Dec 2022 09:23:52 -0800
From:   Jakub Kicinski <kuba@kernel.org>
To:     Leon Romanovsky <leon@kernel.org>
Cc:     Veerasenareddy Burru <vburru@marvell.com>,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Paolo Abeni <pabeni@redhat.com>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Liron Himi <lironh@marvell.com>,
        Abhijit Ayarekar <aayarekar@marvell.com>,
        Sathesh B Edara <sedara@marvell.com>,
        Satananda Burla <sburla@marvell.com>,
        "linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>
Subject: Re: [EXT] Re: [PATCH net-next v2 2/9] octeon_ep: poll for control
 messages
Message-ID: <20221206092352.7a86a744@kernel.org>
In-Reply-To: <Y48ERxYICkG9lQc1@unreal>
References: <20221129130933.25231-1-vburru@marvell.com>
        <20221129130933.25231-3-vburru@marvell.com>
        <Y4cirWdJipOxmNaT@unreal>
        <BYAPR18MB242397C352B0086140106A46CC159@BYAPR18MB2423.namprd18.prod.outlook.com>
        <Y4hhpFVsENaM45Ho@unreal>
        <BYAPR18MB2423229A66D1C98C6C744EE1CC189@BYAPR18MB2423.namprd18.prod.outlook.com>
        <Y42nerLmNeAIn5w9@unreal>
        <20221205161626.088e383f@kernel.org>
        <Y48ERxYICkG9lQc1@unreal>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Tue, 6 Dec 2022 10:58:47 +0200 Leon Romanovsky wrote:
> > 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.

No doubt, if there is an alternative we can push for it to be
implemented. I guess this being yet another "IPU" there could
be possible workarounds in FW? As always with IPUs - hard to tell :/

If there is no alternative - it is what it is. 
It's up to customers to buy good HW.

That said, looking at what this set does - how are the VFs configured?
That's the showstopper for the series in my mind.