[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKgT0UdEP9ZMnNjSSqh-vZvaEc9N8_X_KWvykChxRv1bretYtw@mail.gmail.com>
Date: Thu, 21 Apr 2016 12:22:38 -0700
From: Alexander Duyck <alexander.duyck@...il.com>
To: Babu Moger <babu.moger@...cle.com>
Cc: Jeff Kirsher <jeffrey.t.kirsher@...el.com>,
"Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
shannon nelson <shannon.nelson@...el.com>,
Carolyn Wyborny <carolyn.wyborny@...el.com>,
"Skidmore, Donald C" <donald.c.skidmore@...el.com>,
Bruce W Allan <bruce.w.allan@...el.com>,
John Ronciak <john.ronciak@...el.com>,
Mitch Williams <mitch.a.williams@...el.com>,
intel-wired-lan <intel-wired-lan@...ts.osuosl.org>,
Netdev <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Sowmini Varadhan <sowmini.varadhan@...cle.com>
Subject: Re: [PATCH] ixgbevf: Fix relaxed order settings in VF driver
On Thu, Apr 21, 2016 at 11:13 AM, Alexander Duyck
<alexander.duyck@...il.com> wrote:
> On Thu, Apr 21, 2016 at 10:21 AM, Babu Moger <babu.moger@...cle.com> wrote:
>> Current code writes the tx/rx relaxed order without reading it first.
>> This can lead to unintended consequences as we are forcibly writing
>> other bits.
>
> The consequences were very much intended as there are situations where
> enabling relaxed ordering can lead to data corruption.
>
>> We noticed this problem while testing VF driver on sparc. Relaxed
>> order settings for rx queue were all messed up which was causing
>> performance drop with VF interface.
>
> What additional relaxed ordering bits are you enabling on Sparc? I'm
> assuming it is just the Rx data write back but I want to verify.
>
>> Fixed it by reading the registers first and setting the specific
>> bit of interest. With this change we are able to match the bandwidth
>> equivalent to PF interface.
>>
>> Signed-off-by: Babu Moger <babu.moger@...cle.com>
>
> Fixed is a relative term here since you are only chasing performance
> from what I can tell. We need to make certain that this doesn't break
> the driver on any other architectures by leading to things like data
> corruption.
>
> - Alex
It occurs to me that what might be easier is instead of altering the
configuration on all architectures you could instead wrap the write so
that on SPARC you include the extra bits you need and on all other
architectures you leave the write as-is similar to how the code in the
ixgbe_start_hw_gen2 only clears the bits if CONFIG_SPARC is not
defined.
- Alex
Powered by blists - more mailing lists