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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Fri, 20 Jun 2008 16:20:29 -0700 (PDT)
From:	David Miller <>
Subject: Re: [PATCH 3/3]: tg3: Manage TX backlog in-driver.

From: Krishna Kumar2 <>
Date: Fri, 20 Jun 2008 16:18:35 +0530

> Couple of comments:
> 1. The modified drivers has a backlog of upto tx_queue_len skbs
>     compared to unmodified drivers which had tx_queue_len+q->limit.
>     Won't this result in a performance hit since packet drops will
>     take place earlier?

I doubt it matters when the tx_queue_len is on the order of 1000
packets as it currently is for ethernet devices .  For single stream
TCP tests I've never seen the backlog climb past 128 packets or so.

> 2. __tg3_xmit_backlog() should check for not running too long. This
>     also means calling netif_schedule() if tx_backlog is !empty, to
>     avoid rotting packets in the backlog queue.

I'm not so sure this is an issue in practice.  We can measure
it later to make sure.

The heuristics in the driver only wake up with the wakeup threshold
number of slots become available.  So I don't think we ever batch up
more than a certain amount of work.

But I agree it is important to consider this.
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists