Linas-san, > > GDTDCEIDIS flag is defined that it is for debug and should not be used. > > !? Certainly, my spec doesn't say anything like this;
First, I'm sorry to say that GDTDCEDIS is for debug. It's my misunderstanding. My HW manual of SCC simply said that GDTDCEDIS must not be set(Is it same for you?). But I don't know concretely what will go wrong by setting this bit. > I don't know of any other way of turning off the descriptor > chain end interrupt; leaving it on hurts performance in a big way. > > I get the following TX performance numbers: > > pkt sz rate w/o patch rate w/patch > (bytes) (Mbits/sec) (Mbits/sec) > ------- ---------- --------- > 400 503 353 > 200 239 88 > 100 122 44 > 60 73 26 > > That's not quite a 3x performance degradation. > > In addition, with your patch, the number of interrupts jumps > from just about zero, to about 55K/second. From what I can tell, > this huge interrupt rate eats up all the CPU cycles, which is > why the performance drops so drasically. I understand the influence for performance by setting GDTDCEDIS and why you set this bit. > > We met some troubles on Celleb platform by setting this flag. > > -network does not recover after ifconfig down, then up operations. > > Can you be more specific? I can't imagine why this flag would > have anything to do with ifdown/ifup. The device open/close > routines should reset all hardware state; this shouldn't make > any difference. (It doesn't for me, at least). Sorry, I have no more information that ifconfig down/up commands. All about I know is that I met the phenomenon when GDTDCEDIS is set. I need more investigation. Please drop the patch. Best regards, Kou Ishizaki - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
