[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.03.1502031326260.22700@ws.cisco>
Date: Tue, 3 Feb 2015 15:19:30 +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 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?
> You need to actually design this facility properly, understand
> what the needs are of other drivers and how this facility
> can be relevant for more drivers than your own.
>
--
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