RE: packet generator

From: Andrew Gallatin (gallatin_at_cs.duke.edu)
Date: 09/15/04

  • Next message: Eric W. Bates: "Re: To many dynamic rules created by infected machine"
    Date: Tue, 14 Sep 2004 18:02:36 -0400 (EDT)
    To: "Don Bowman" <don@sandvine.com>
    
    
    

    Andrew Gallatin writes:

    > xmit routine was called 683441 times. This means that the queue was
    > only a little over two packets deep on average, and vmstat shows idle
    > time. I've tried piping additional packets to nghook mx0:orphans
    > input, but that does not seem to increase the queue depth.
    >

    The problem here seems to be that rather than just slapping the
    packets onto the driver's queue, ng_source passes the mbuf down
    to more of netgraph, where there is at least one spinlock,
    and the driver's ifq lock is taken and released a zillion times
    by ether_output_frame(), etc.

    A quick hack (appended) to just slap the mbufs onto the if_snd queue
    gets me from ~410Kpps to 1020Kpps. I also see very deep queues
    with this (because I'm slamming 4K pkts onto the queue at once..).

    This is nearly identical to the linux pktgen figure on the same
    hardware, which makes me feel comfortable that there is a lot of
    headroom in the driver/firmware API and I'm not botching something
    in the FreeBSD driver.

    BTW, did you see your 800Kpps on 4.x or 5.x? If it was 4.x, what do
    you see on 5.x if you still have the same setup handy?

    Thanks,

    Drew

    
    
    

    _______________________________________________
    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: Eric W. Bates: "Re: To many dynamic rules created by infected machine"

    Relevant Pages

    • RE: packet generator
      ... >> only a little over two packets deep on average, ... but that does not seem to increase the queue depth. ... > packets onto the driver's queue, ng_source passes the mbuf down ... > headroom in the driver/firmware API and I'm not botching something ...
      (freebsd-net)
    • Re: 3COM ep0 pccard device broken in current.
      ... Fix a race condition that was introduced since pccbb interrupts are ... use the IF_DEQUEUE macro to ... The old code was first getting the mbuf by taking it from the queue ...
      (freebsd-current)
    • Re: 3COM ep0 pccard device broken in current.
      ... "M. Warner Losh" writes: ... > The old code was first getting the mbuf by taking it from the queue ... > without using the macros, thus without locking, and without removing ... > it from the queue either. ...
      (freebsd-current)