Linux Virtualization - Jan 2014 - [PATCH net-next v3 4/5] net-sysfs: add support for device-specific rx queue sysfs attributes

On Thu, 2014-01-16 at 11:07 -0800, Michael Dalton wrote:
> On Jan 16, 2014 at 10:57 AM, Ben Hutchings <bhutchings at
solarflare.com> wrote:
> > Why write a loop when you can do:
> >         i = queue - dev->_rx;
> Good point, the loop approach was done in get_netdev_queue_index --
> I agree your fix is faster and simpler. I'll fix in next patchset.
It's simpler but we don't know if it's faster (and I don't
believe that
matters for the current usage).

If one of these functions starts to be used in the data path, at that
point it could be worth optimising, e.g. by doing a test for queue 0 and
only then doing the pointer arithmetic with its implicit division.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

On Thu, Jan 16, 2014 Ben Hutchings <bhutchings at solarflare.com>
wrote:
> It's simpler but we don't know if it's faster (and I don't
believe that
> matters for the current usage).
>
> If one of these functions starts to be used in the data path, at that
> point it could be worth optimising, e.g. by doing a test for queue 0 and
> only then doing the pointer arithmetic with its implicit division.
Good catch, my statement above is incorrect. We don't know if this change
is a performance win, and it does introduce an implicit div. I agree this
function is not currently performance critical and is used only by for
reporting values to sysfs.

Best,

Mike

On Thu, 2014-01-16 at 11:51 -0800, Michael Dalton wrote:
> On Thu, Jan 16, 2014 Ben Hutchings <bhutchings at solarflare.com>
wrote:
> > It's simpler but we don't know if it's faster (and I
don't believe that
> > matters for the current usage).
> >
> > If one of these functions starts to be used in the data path, at that
> > point it could be worth optimising, e.g. by doing a test for queue 0
and
> > only then doing the pointer arithmetic with its implicit division.
> Good catch, my statement above is incorrect. We don't know if this
change
> is a performance win, and it does introduce an implicit div. I agree this
> function is not currently performance critical and is used only by for
> reporting values to sysfs.
gcc usually do not emit a divide instruction to perform a divide by a
constant, but uses a reciprocal operation (basically a multiply and a
shift)

So I am pretty sure this is faster than the loop.