Re: 64 bit packet counters

From: Jesper Skriver (jesper_at_FreeBSD.org)
Date: 11/09/03

  • Next message: Andre Oppermann: "tcp hostcache and ip fastforward for review"
    Date: Sun, 9 Nov 2003 15:11:32 +0100
    To: Harti Brandt <brandt@fokus.fraunhofer.de>
    
    

    On Sat, Nov 08, 2003 at 10:13:48AM +0100, Harti Brandt wrote:

    > On Fri, 7 Nov 2003, Alex Hoff wrote:
    >
    > AH>Hi,
    > AH>
    > AH>We are attempting to implement the IF-MIB, which requires the
    > AH>use of 64 bit packet counters and the differentiation between
    > AH>multicast and broadcast pkts. Since changing the if_data (by
    > AH>adding new counters and changing the existing to u_int64) is a bad
    > AH>idea, does anyone have any good ideas on how to do this? I was
    > AH>thinking of tacking on a new struct (lets call it ifx_data) on at
    > AH>the end of the current if_net struct with the appropriate counters
    > AH>(i/opacket, i/obyte, i/obcast, i/omcast). Apart from having to do
    > AH>a little double counting is there any obvious pitfals with this
    > AH>approach? Does anyone have an better ideas? Is there currently any
    > AH>plans to update the network stack to handle this properly?
    >
    > You may lookup the discussions in the mailing lists. As far as
    > I remember the problem with 64 bit counting was that this needs
    > locks because not on all architectures you have atomic 64bit add
    > operations. A simple method that does not involve kernel changes (and
    > that I plan to implement in my snmp daemon) is to periodically monitor
    > the counters (depending on the interface speed) and detect wraps in
    > the daemon.

    What is done in other places is to have normal 32 bit counters that are
    incremented per packet, and have a background task/thread to update the
    64 bit counters from the 32 bit counters.

    That way, we avoid the locking issue per packet.

    /Jesper

    -- 
    Jesper Skriver, jesper(at)skriver(dot)dk  -  CCIE #5456
    One Unix to rule them all, One Resolver to find them,
    One IP to bring them all and in the zone to bind them.
    _______________________________________________
    freebsd-net@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-net
    To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
    

  • Next message: Andre Oppermann: "tcp hostcache and ip fastforward for review"

    Relevant Pages

    • Re: Speed Mismatch?!?
      ... This _is_ a clue. ... all gi...I _WAS_ trying to buffer somthing somwhere, ... how but wondering if packet A overran packet B to the point that the ... interface counters care what goes on between the guts that contect ...
      (comp.dcom.sys.cisco)
    • Re: 64 bit packet counters
      ... AH>packet counters and the differentiation between multicast and broadcast ... You may lookup the discussions in the mailing lists. ... snmp daemon) is to periodically monitor the counters (depending on the ...
      (freebsd-net)
    • Re: Strange issue with NDISPROT xmit and the network performance counter
      ... It seems that the packet counters in the NIC are different from the counters ... from the Task Manager counts only IP packets and completely ignores my ... custom Ethernet frames. ...
      (microsoft.public.development.device.drivers)
    • Occasional delay in processing incoming packets
      ... I have a problem where occasionally a packet is not ... I get the exact same behavior with ADO 2.8 and ADO.NET. ... and the time Profiler claims SQL Server started ... I've tried to run perfmon on the obvious counters on the database but ...
      (microsoft.public.sqlserver.server)