netstat -B "Recv"

[elof2 at sentor.se]

On Thu, 5 Nov 2015, Alexander V. Chernikov wrote:

>
>
> 04.11.2015, 19:55, "elof2 at sentor.se" <elof2 at sentor.se>:
>> Hi!
>>
>> Question:
>> What do the Recv column in 'netstat -B' show?
>>
>> I thought it was tha amount of packets received, but appaently not so.
>>
>> I send 2000000 packets from a tcpreplay machine to a receiving machine.
>> I do it a few times.
>>
>> On the receiver I see:
>> netstat -in
>> Name Mtu Network Address Ipkts Ierrs Idrop Opkts
>> Oerrs Coll
>> ix0 1500 <Link#1> 0c:c4:7a:58:e2:3c 0 0 0 0
>> 0 0
>> ix1 1500 <Link#2> 0c:c4:7a:58:e2:3d 6000000 0 0 0
>> 0 0
>>
>> and then
>> netstat -in
>> Name Mtu Network Address Ipkts Ierrs Idrop Opkts
>> Oerrs Coll
>> ix0 1500 <Link#1> 0c:c4:7a:58:e2:3c 0 0 0 0
>> 0 0
>> ix1 1500 <Link#2> 0c:c4:7a:58:e2:3d 8000000 0 0 0
>> 0 0
>>
>> So 6000000 has increased to 8000000. Good.
>>
>> However, 'netstat -B' show:
>>    Pid Netif Flags Recv Drop Match Sblen Hblen Command
>> 25553 mon0 p--s--- 1996862 0 2000000 0 0 tcpdump
>>
>> How can the "Recv" be *lower* than "Match"?
>> 1996862 < 2000000.
>>
>> For every new run (fast and slow) I get the same results, slightly less
>> than 2000000 Recv.
>>
>> What am I missing?
> Well, "Recv" is read from d->bd_rcount which is not per-cpu counter and is incrementing unlocked.
> On the other hand, "Match" increases when filter returned match condition and we (w)locked bpf descriptor, so this one is accurate.

Ah. Thanks.


Will you make a bugzilla out of this? Or should I? Or is it not 
interesting enough to fix?

/Elof