netdev - Re: [PATCH] macvlan: lockless tx path

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 11 Nov 2010 09:20:53 -0800
From:	Ben Greear <greearb@...delatech.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
CC:	netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH] macvlan: lockless tx path

On 11/11/2010 08:56 AM, Eric Dumazet wrote:
> Le jeudi 11 novembre 2010 à 08:40 -0800, Ben Greear a écrit :
>
>> So, they assume counters are exactly 32 or 64 bits.
>> Your example of the 36-bit counter would break their
>> assumptions of 32 or 64 bits.
>>
>
> They 'assume'. I am not. How do you handle counters that suddenly go to
> 0 ?

I've shown you my algorithm that requires one to know the counter
width, and in response you offered on that will work with 32 OR 64 bits,
as long as you make some assumptions.

If you have an algorithm that can properly deal with wrapped counters of
arbitrary bits, then post it.

As for counters that go to zero, if the previous value was > 0, then
it was a wrap.  There is a reason Dave won't let anyone add a patch to
clear network counters.  If the network device was removed and came back,
then you must listen for those events and take proper precautions (set
prev to 0 before sampling any counters, for instance).

>> I agree that you can guess if the counter is 32 or 64, at least with today's
>> hardware and relatively normal poll times, and the requirement that the
>> counters can ONLY be 32 or 64 bits.  I still consider it a kludge to
>> return 32 bit counters in stats64, however.  Would you consider
>> a patch to have netlink pay attention to whether the stats are 32 or
>> 64 (based on a flag returned from dev_get_stats perhaps)?
>
> So what ? How is it going to help /proc/net/dev users (most apps use it)

At least they will have an opportunity to use a better defined API
if they wish.  And, if you only want stats for one interface, and
you have 4000 VLANs in the system, reading /proc/net/dev seems quite
inefficient.

> Could you please adapt your software, and not adapt linux to your
> needs ? Dont your software runs on linux 2.6.32 ?

Yes, I used to carry a patch that allowed direct access to the netdev_stats,
and I'd fall back to parsing /proc/net/dev on standard kernels.  I've now
moved to using netlink API as that seems the preferred method going
forward and allows the granularity (ie, get stats for a single device)
that I prefer.

And, I'll certainly keep trying to improve Linux, because if it helps
my needs, it may help others.  If it causes harm to others, then hopefully
someone will notice and reject my patch or help me to see how to make
it better.

Thanks,
Ben

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

--
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