[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.03.1502052215490.11051@ws.cisco>
Date: Thu, 5 Feb 2015 22:58:26 +0530 (IST)
From: Govindarajulu Varadarajan <_govind@....com>
To: David Miller <davem@...emloft.net>
cc: _govind@....com, netdev@...r.kernel.org, ssujith@...co.com,
benve@...co.com, edumazet@...gle.com, ben@...adent.org.uk
Subject: Re: [PATCH net-next 3/4] ethtool: add RX_ALLOC_ORDER to tunable
On Tue, 3 Feb 2015, Govindarajulu Varadarajan wrote:
> On Mon, 2 Feb 2015, David Miller wrote:
>
>> From: Govindarajulu Varadarajan <_govind@....com>
>> Date: Sat, 31 Jan 2015 17:58:09 +0530
>>
>>> Signed-off-by: Govindarajulu Varadarajan <_govind@....com>
>>
>> This is terrible.
>>
>> You haven't explained what this means.
>>
>> And to tell you the truth, from what I can tell this tunable is
>> very specific to how you have implemented RX frags in the enic
>> driver in this series and won't necessarily translate to how
>> other drivers manage RX buffers.
>>
>
> Yes I agree that this is too specific to driver. From my knowledge mlx4 also
> uses similar frag allocation from large order page. Other that these two
> drivers, this facility may not make sense to other drivers.
>
> On systems with huge memory we can go higher than order-3, and if user sees
> that
> order-3 are failing, he should be able to reduce the order.
>
> Since this is very driver specific, are you fine if I move this to device
> sysfs?
>
I hope there are no issues with the patch 1 & 2. Should I drop the
'changing order' patches and resend patch 1 & 2 alone?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists