Re: [PATCH][E1000E] some cleanups

Previous thread: ehea work queues by Anton Blanchard on Sunday, September 30, 2007 - 9:20 am. (2 messages)

Next thread: [PATCH][TG3]Some cleanups by jamal on Sunday, September 30, 2007 - 11:11 am. (9 messages)
From: jamal
Date: Sunday, September 30, 2007 - 10:41 am

Auke,

heres part of something i promised. 
I couldnt do any packet testing on because 82571EB is disabled in the
driver. I uncommented the code out in the table, but the best i could
get was the module loading, some probing and some sysfs renaming
failures (probably a debianism); the machine access is intermittent, so
thats as far as i could go. In any case, you probably have a good reason
for disabling that chip. So, heres the patch, the burden of testing now
falls on you ;->
Once you have 82571EB on and kicking, my next steps are to kill LLTX
then add batching on top.
BTW, since this driver is just for PCIE, would you take a similar patch
for non-PCIE e1000?

comment:
There used to be an "mmiowb()" call right after the dma wake which is
gone now; is this unneeded with pcie? I have restored it, look for the
"XXX".

cheers,
jamal
From: Kok, Auke
Date: Sunday, September 30, 2007 - 11:16 am

no, all the hardware that is commented should work just fine. I tested this driver
on 82571, 82573 and ich8/ich9 - extensively.

the reason that we disable them is that we're going to migrate devices over in
batches. At introduction we'll support ich9, afterwards we'll drop in the IDs of



thanks, I'll go and look at this in depth in the coming weeks.

Auke
-

From: jamal
Date: Sunday, September 30, 2007 - 12:01 pm

Something else is wrong then. Can you just uncomment the 82571EB bits in
Dave's net-2.6.24 and just send a ping? If it works, let me know what


It just makes it easier to kill LLTX. If you consider killing LLTX
risky, then i will focus on e1000e.

cheers,
jamal

-

From: Jeff Garzik
Date: Sunday, September 30, 2007 - 12:23 pm

Gotta wait a bit, otherwise we have confusion and a bit of breakage from 
two drivers with the same PCI IDs.

	Jeff


-

From: jamal
Date: Sunday, September 30, 2007 - 12:31 pm

ah, ok ;-> 
When i was testing i compiled out e1000. I am willing to totaly migrate
to e1000e, since major machine i have access to has PCIE. Auke, just let
me know what you need to do other than uncommenting the table entries
and i will leave you alone ;->

cheers,
jamal


-

From: Kok, Auke
Date: Sunday, September 30, 2007 - 6:59 pm

the IDs are the only thing needed to enable all pci-e e1000 hardware.

by all means we need to have guys like you and Jeff test the commented IDs! I've
been doing this myself and the e1000e driver goes to our labs for a period of
testing from next week. Unfortunately they don't know how to break it that good as
some of you guys ;)

I'll personally try to get an 82571EB tested on monday.

Auke
-

From: jamal
Date: Tuesday, October 2, 2007 - 5:25 am

I'll give it a whirl in the next few days. It failed as a module (with
e1000 compiled out), i will try to compile it in. I have access to the

How did that go?

cheers,
jamal

-

From: Kok, Auke
Date: Tuesday, October 2, 2007 - 10:06 am

Emil just ran overnight testing on a 82571, a 81572, a ich9 and an esb2 onboard
LOM. All passed traffic OK. There was one issue/unconfirmed bug with jumbo frames
that I'm currently looking at, but nothing at normal MTU's.

So, you should be just fine using 82571's with e1000e for now.

Auke
-

From: Kok, Auke
Date: Tuesday, October 2, 2007 - 10:43 am

the description of this patch is rather misleading, and the title certainly too.
Can you resend this with a bit more elaborate explanation as to why the cb code is
relevant to use here? Not only do I need to understand this, but others might want
to as well later on ;)

Cheers,

Auke
-

From: jamal
Date: Wednesday, October 3, 2007 - 6:18 am

I am probably repeating something youve seen/know already.
The cleanup is to break up the code so it is functionally more readable
from a perspective of the 4 distinct parts in ->hard_start_xmit():

a) packet formatting (example: vlan, mss, descriptor counting, etc.)
b) chip-specific formatting
c) enqueueing the packet on a DMA ring
d) IO operations to complete packet transmit, tell DMA engine to chew
on, tx completion interrupts, set last tx time, etc.

Each of those steps sitting in different functions accumulates state
that is used in the next steps. cb stores this state because it a
scratchpad the driver owns. You could create some other structure and
pass it around the iteration, but why waste more bytes.

batching work. Thats how we started this discussion ;-> I would like,
once converted the driver to remove LLTX, to do #a without holding the
tx lock. This stands on its own even without batching. Then of course,
once all this is in such good shape it makes it easier to add the
batching code because i could reuse the now functionalized steps.
I hope that provides reasonable and good explanation ;->

cheers,
jamal

-

From: jamal
Date: Sunday, October 7, 2007 - 9:15 am

Ok, here you go; the explanation is below. This is from net-2.6.24 of
early this AM. I saw a patch you posted that is derived from Krishna;
although it hasnt showed up in the tree - i have considered those
changes and this patch adds a little more optimization in case of
errors.

I will send you a patch to kill LLTX the sooner this shows up somewhere.

cheers,
jamal


From: Kok, Auke
Date: Monday, October 8, 2007 - 3:40 pm

thanks.

My biggest problem with the patch as you sent it that it's a tonload of changes
and no implicit benefit immediately as I can see. I would really have to see the
LLTX change as well to make a wellfounded decision whether it is the right thing
to go and overhaul this part of the driver or not :)

I'm not particularly against the changes per se though.

so please, if needed offlist send me those LLTX changes as well.

-

From: jamal
Date: Tuesday, October 9, 2007 - 6:29 am

The patch looks scary but is pretty tame when you apply it and stare at

Dont worry about it - i didnt get any love for a similar patch i did for
tg3 either ;-> I will hold onto it for now. I could do the un-LLTX
outside of this - would you like that for both e1000/e1000e ?

cheers,
jamal

-

From: Kok, Auke
Date: Tuesday, October 9, 2007 - 9:02 am

if we're going to remove LLTX from e1000 I prefer to do that at a much later time.
Let's focus on e1000e instead - while it is still moving ;)

Auke
-

From: jamal
Date: Tuesday, October 9, 2007 - 3:18 pm

I think you may be in luck ;-> I just saw a patch posted by jgarzik
which touched both e1000/e LLTX. I am on travel mode starting tommorow,
I will try to extract it on my laptop while on the road but cant test
it.

cheers,
jamal

-

Previous thread: ehea work queues by Anton Blanchard on Sunday, September 30, 2007 - 9:20 am. (2 messages)

Next thread: [PATCH][TG3]Some cleanups by jamal on Sunday, September 30, 2007 - 11:11 am. (9 messages)