[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1497875168290.26033@amazon.com>
Date: Mon, 19 Jun 2017 12:26:08 +0000
From: "Belgazal, Netanel" <netanel@...zon.com>
To: David Miller <davem@...emloft.net>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"Woodhouse, David" <dwmw@...zon.co.uk>,
"Machulsky, Zorik" <zorik@...zon.com>,
"Matushevsky, Alexander" <matua@...zon.com>,
"BSHARA, Said" <saeedb@...zon.com>,
"Wilson, Matt" <msw@...zon.com>,
"Liguori, Anthony" <aliguori@...zon.com>,
"Bshara, Nafea" <nafea@...zon.com>,
"Schmeilin, Evgeny" <evgenys@...zon.com>
Subject: Re: [PATCH net-next 10/13] net: ena: add mtu limitation in
ena_change_mtu()
I'll discard this patch.
________________________________________
From: David Miller <davem@...emloft.net>
Sent: Sunday, June 18, 2017 7:21 PM
To: Belgazal, Netanel
Cc: netdev@...r.kernel.org; Woodhouse, David; Machulsky, Zorik; Matushevsky, Alexander; BSHARA, Said; Wilson, Matt; Liguori, Anthony; Bshara, Nafea; Schmeilin, Evgeny
Subject: Re: [PATCH net-next 10/13] net: ena: add mtu limitation in ena_change_mtu()
From: <netanel@...zon.com>
Date: Sun, 18 Jun 2017 14:28:15 +0300
> From: Netanel Belgazal <netanel@...zon.com>
>
> Signed-off-by: Netanel Belgazal <netanel@...zon.com>
I don't understand this at all.
This whole reason we have those:
> @@ -3008,8 +3015,6 @@ static void ena_set_conf_feat_params(struct ena_adapter *adapter,
> ena_set_dev_offloads(feat, netdev);
>
> adapter->max_mtu = feat->dev_attr.max_mtu;
> - netdev->max_mtu = adapter->max_mtu;
> - netdev->min_mtu = ENA_MIN_MTU;
> }
>
assignments you are removing is so that the core networking can
validate the request and therefore individual drivers don't have to.
If it's just to get that silly driver message out when the MTU asked
for is too large, that's not a good reason to bypass the
infrastructure for MTU changes that we've provided for drivers in the
core.
I don't like this change at all.
You could have helped things a lot by actually writing a commit log
message explaining what you are really doing, and why you are doing
it. Empty commit log messages are never a good idea.
Powered by blists - more mailing lists