Date: Fri, 6 Nov 2015 14:22:29 -0600 From: Christian Peron <csjp@sqrt.ca> To: elof2@sentor.se Cc: "Alexander V. Chernikov" <melifaro@freebsd.org>, freebsd-net <freebsd-net@freebsd.org> Subject: Re: netstat -B "Recv" Message-ID: <884C10B2-9C17-44C6-81AC-1C56548FE31D@sqrt.ca> In-Reply-To: <alpine.BSF.2.00.1511051518330.49057@farmermaggot.shire.sentor.se> References: <null> <alpine.BSF.2.00.1511041736240.49057@farmermaggot.shire.sentor.se> <111891446726660@web29h.yandex.ru> <alpine.BSF.2.00.1511051518330.49057@farmermaggot.shire.sentor.se>
next in thread | previous in thread | raw e-mail | index | archive | help
It needs to get fixed.. let me generate a patch for you and you can test = it. > On Nov 5, 2015, at 8:51 AM, elof2@sentor.se wrote: >=20 > On Thu, 5 Nov 2015, Alexander V. Chernikov wrote: >=20 >>=20 >>=20 >> 04.11.2015, 19:55, "elof2@sentor.se" <elof2@sentor.se>: >>> Hi! >>>=20 >>> Question: >>> What do the Recv column in 'netstat -B' show? >>>=20 >>> I thought it was tha amount of packets received, but appaently not = so. >>>=20 >>> I send 2000000 packets from a tcpreplay machine to a receiving = machine. >>> I do it a few times. >>>=20 >>> 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 >>>=20 >>> 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 >>>=20 >>> So 6000000 has increased to 8000000. Good. >>>=20 >>> However, 'netstat -B' show: >>> Pid Netif Flags Recv Drop Match Sblen Hblen Command >>> 25553 mon0 p--s--- 1996862 0 2000000 0 0 tcpdump >>>=20 >>> How can the "Recv" be *lower* than "Match"? >>> 1996862 < 2000000. >>>=20 >>> For every new run (fast and slow) I get the same results, slightly = less >>> than 2000000 Recv. >>>=20 >>> 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. >=20 > Ah. Thanks. >=20 >=20 > Will you make a bugzilla out of this? Or should I? Or is it not = interesting enough to fix? >=20 > /Elof > _______________________________________________ > freebsd-net@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?884C10B2-9C17-44C6-81AC-1C56548FE31D>