[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKgT0Uc2ztu_iDn79zdNtsAdb-Ftu65V6YHV-sqXb6vTCTiGCQ@mail.gmail.com>
Date: Thu, 22 Dec 2016 07:53:42 -0800
From: Alexander Duyck <alexander.duyck@...il.com>
To: maowenan <maowenan@...wei.com>
Cc: Stephen Hemminger <stephen@...workplumber.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"jeffrey.t.kirsher@...el.com" <jeffrey.t.kirsher@...el.com>,
"weiyongjun (A)" <weiyongjun1@...wei.com>,
Dingtianhong <dingtianhong@...wei.com>
Subject: Re: [PATCH] ethtool: add one ethtool option to set relax ordering mode
On Wed, Dec 21, 2016 at 5:39 PM, maowenan <maowenan@...wei.com> wrote:
>
>
>> -----Original Message-----
>> From: Stephen Hemminger [mailto:stephen@...workplumber.org]
>> Sent: Thursday, December 22, 2016 9:28 AM
>> To: maowenan
>> Cc: netdev@...r.kernel.org; jeffrey.t.kirsher@...el.com
>> Subject: Re: [PATCH] ethtool: add one ethtool option to set relax ordering mode
>>
>> On Thu, 8 Dec 2016 14:51:38 +0800
>> Mao Wenan <maowenan@...wei.com> wrote:
>>
>> > This patch provides one way to set/unset IXGBE NIC TX and RX relax
>> > ordering mode, which can be set by ethtool.
>> > Relax ordering is one mode of 82599 NIC, to enable this mode can
>> > enhance the performance for some cpu architecure.
>>
>> Then it should be done by CPU architecture specific quirks (preferably in PCI
>> layer) so that all users get the option without having to do manual intervention.
>>
>> > example:
>> > ethtool -s enp1s0f0 relaxorder off
>> > ethtool -s enp1s0f0 relaxorder on
>>
>> Doing it via ethtool is a developer API (for testing) not something that makes
>> sense in production.
>
>
> This feature is not mandatory for all users, acturally relax ordering default configuration of 82599 is 'disable',
> So this patch gives one way to enable relax ordering to be selected in some performance condition.
That isn't quite true. The default for Sparc systems is to have it enabled.
Really this is something that is platform specific. I agree with
Stephen that it would work better if this was handled as a series of
platform specific quirks handled at something like the PCI layer
rather than be a switch the user can toggle on and off.
With that being said there are changes being made that should help to
improve the situation. Specifically I am looking at adding support
for the DMA_ATTR_WEAK_ORDERING which may also allow us to identify
cases where you might be able to specify the DMA behavior via the DMA
mapping instead of having to make the final decision in the device
itself.
- Alex
Powered by blists - more mailing lists