linux-kernel - Re: [RFC PATCH] net:Add basic DWC Ethernet QoS Driver

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] [day] [month] [year] [list]

Date:	Thu, 08 May 2014 16:26 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Andreas Irestål <andreas.irestal@...s.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"grant.likely@...aro.org" <grant.likely@...aro.org>,
	"robh+dt@...nel.org" <robh+dt@...nel.org>,
	"davem@...emloft.net" <davem@...emloft.net>,
	"maxime.ripard@...e-electrons.com" <maxime.ripard@...e-electrons.com>,
	"abrodkin@...opsys.com" <abrodkin@...opsys.com>,
	"jeffrey.t.kirsher@...el.com" <jeffrey.t.kirsher@...el.com>,
	"ben@...adent.org.uk" <ben@...adent.org.uk>,
	"sr@...x.de" <sr@...x.de>,
	"jonas.jensen@...il.com" <jonas.jensen@...il.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Jesper Nilsson <jespern@...s.com>, peppe.cavallaro@...com
Subject: Re: [RFC PATCH] net:Add basic DWC Ethernet QoS Driver

On Thursday 08 May 2014 16:18:04 Andreas Irestål wrote:
> 
> > > +
> > > +   /* Set poll wait timeout to 2 seconds */
> > > +   dwc_wait = 200;
> > > +
> > > +   while (lp->tx_descs[i].tdes3.wr.own) {
> > > +           mdelay(10);
> > > +           if (!dwc_wait--)
> > > +                   break;
> > > +   }
> > 
> > This is really evil: you are blocking the CPU for up to two seconds!
> > You already mentioned that this is work-in-progress, but I guess it has
> > to be a little better than this and do something that doesn't block
> > out the CPU during TX.
> > 
> 
> It really is, but a 2s lockout is only happening upon TX failure. Anyway, this
> won't be an issue in the final version, since it won't use polling for TX.

Actually I'd expect a 10ms delay for most packets, which is also too much.

Just for scale: at gigabit speed, a 10 *microsecond* delay would be more
appropriate than a 10 milisecond delay. Anyway, it's not important here as
long as you find a proper solution.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/