[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DB8PR04MB67644D35E9D45F757CB4F76396780@DB8PR04MB6764.eurprd04.prod.outlook.com>
Date: Tue, 21 Jul 2020 08:00:46 +0000
From: Claudiu Manoil <claudiu.manoil@....com>
To: Jakub Kicinski <kuba@...nel.org>
CC: "David S . Miller" <davem@...emloft.net>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [PATCH net-next v2 5/6] enetc: Add interrupt coalescing support
>-----Original Message-----
>From: Jakub Kicinski <kuba@...nel.org>
>Sent: Monday, July 20, 2020 7:59 PM
[...]
>Subject: Re: [PATCH net-next v2 5/6] enetc: Add interrupt coalescing support
>
>On Sat, 18 Jul 2020 20:20:10 +0300 Claudiu Manoil wrote:
>> On 17.07.2020 22:32, Jakub Kicinski wrote:
>> > On Fri, 17 Jul 2020 18:37:03 +0300 Claudiu Manoil wrote:
>> >> + if (ic->rx_max_coalesced_frames != ENETC_RXIC_PKTTHR)
>> >> + netif_warn(priv, hw, ndev, "rx-frames fixed to %d\n",
>> >> + ENETC_RXIC_PKTTHR);
>> >> +
>> >> + if (ic->tx_max_coalesced_frames != ENETC_TXIC_PKTTHR)
>> >> + netif_warn(priv, hw, ndev, "tx-frames fixed to %d\n",
>> >> + ENETC_TXIC_PKTTHR);
>> >
>> > On second thought - why not return an error here? Since only one value
>> > is supported seems like the right way to communicate to the users that
>> > they can't change this.
>>
>> Do you mean to return -EOPNOTSUPP without any error message instead?
>
>Yes.
>
>> If so, I think it's less punishing not to return an error code and
>> invalidate the rest of the ethtool -C parameters that might have been
>> correct if the user forgets that rx/tx-frames cannot be changed.
>
>IMHO if configuring manually - user can correct the params on the CLI.
>If there's an orchestration system trying to configure those - it's
>better to return an error and alert the administrator than confuse
>the orchestration by allowing a write which is then not reflected
>on read.
>
Good point, ok. Updated accordingly in v3.
Thanks.
Powered by blists - more mailing lists