netdev - Re: [Cbe-oss-dev] [PATCH] spidernet: don't use debug flag

lists.openwall.net		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 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200707110758.l6B7w1Jc026926@toshiba.co.jp>
Date:	Wed, 11 Jul 2007 16:57:38 +0900 (JST)
From:	Ishizaki Kou <kou.ishizaki@...hiba.co.jp>
To:	linas@...tin.ibm.com
Cc:	kou.ishizaki@...hiba.co.jp, netdev@...r.kernel.org,
	cbe-oss-dev@...abs.org
Subject: Re: [Cbe-oss-dev] [PATCH] spidernet: don't use debug flag

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html