On Wed, 2007-04-07 at 09:49 +0530, Krishna Kumar2 wrote:
Do you see any contention for tx_lock which can justify having a prep
handler? As I understood, no other CPU can be in the xmit code at the
same time since RUNNING bit is held. Hence getting this lock early or
late should not matter for
On Mon, 2007-02-07 at 17:21 -0700, Michael Chan wrote:
[Matt, please include the count in the fix per previous email]
Only base_flags and mss are needed and these can be determined right
before sending the frame. So is it better not to store these in the
skb-cb at all?
long answer:
My goal
From: jamal [EMAIL PROTECTED]
Date: Tue, 03 Jul 2007 09:09:48 -0400
[It sounds very dangerous to me the way skb-cb is being used by the
vlan code (i.e requires human intervention/knowledge to catch it as an
issue). I had no freaking idea the vlan code was using it. Maybe a huge
comment
On Tue, 2007-03-07 at 12:31 -0700, Matt Carlson wrote:
I had planned on using netperf, but pktgen sounds like a more controlled
environment. Thanks for the tip.
I can help more if you use pktgen - netperf is more involved. Also
pktgen is much closer to the driver so it would let you see
Hi Jamal,
J Hadi Salim [EMAIL PROTECTED] wrote on 07/03/2007 06:56:20 PM:
On Mon, 2007-02-07 at 17:21 -0700, Michael Chan wrote:
[Matt, please include the count in the fix per previous email]
long answer:
My goal with storing these values and computing them was to do certain
things that
On Mon, 2007-07-02 at 14:20 -0700, Matt Carlson wrote:
Also, I think the count, max_per_txd, and nr_frags fields of the
tg3_tx_cbdata struct are not needed.
The count field is not needed also.
+struct tg3_tx_cbdata {
+ u32 base_flags;
+ int count;
+ unsigned int
peoplez,
I have added support for tg3 on batching. I see equivalent performance
improvement for pktgen as i did with e1000 when using gige.
I have only tested on two machines (one being a laptop which does
10/100Mbps). Unfortunately in both cases these are considered to be in
the class of buggy
