Re: [PATCH] macvlan: lockless tx path

[Ben Greear <greearb@candelatech.com>]

On 11/10/2010 10:18 AM, Eric Dumazet wrote:
> Le mercredi 10 novembre 2010 à 09:53 -0800, Ben Greear a écrit :
>
>> I agree, but if these can be read from user-space, it can be tricky to make
>> solid code to deal with wraps when the thing wrapping can be 32 or 64 bits,
>> depending on whether the kernel is compiled 32-bit or 64-bit.
>>
>> So, my preference is to use u32 or u64 so there is no guesswork involved.
>>
>> To be sure, this problem exists in lots of places already (/proc/net/dev comes to mind),
>> but the fewer places the better in my opinion.
>>
>
> On a 32bit kernel, very few devices provide 64bit counters, so an
> application reading /proc/net/dev should be prepared to handle 32 or
> 64bit counter.
>
> On a 64bit kernel, many devices still provide 32, 36, 40 bit counters
> (hardware based). Same conclusion for userspace.

In my opinion, the kernel and/or driver should deal with this such that
at worst the user has to deal with 32 v/s 64 bits based on whether the
kernel is compiled for 32 or 64 bit CPUs.  (Let the driver sample at
intervals needed to never wrap it's counters more than once and update
software stats of well-defined bit-width, and present those software
counters to users.

In practice, this seems to be the case, at least for the NICs I've used
(mostly Intel).  But, please don't propagate the idea that any width of
counters is OK to present to user-space:  It is completely unfair to
make app writers have to know the network driver and/or hardware quirks to
know how often it must sample stats.

> So really, an SNMP application must be able to cope with any counter
> width.
>
> As percpu data is going to hurt in the 4096 cpu cases, we should try to
> not make percpu structures too big.

Well, maybe using u32 would have positive benefits on 64-bit kernels then?

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com