netdev - Re: NAPI and shared interrupt control

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]

Date:	Thu, 7 Dec 2006 02:15:55 -0800
From:	Eugene Surovegin <ebs@...home.net>
To:	David Miller <davem@...emloft.net>
Cc:	benh@...nel.crashing.org, netdev@...r.kernel.org
Subject: Re: NAPI and shared interrupt control

On Thu, Dec 07, 2006 at 01:59:54AM -0800, David Miller wrote:
> From: Eugene Surovegin <ebs@...home.net>
> Date: Thu, 7 Dec 2006 01:45:02 -0800
> 
> > I fail to see how this is not even more ugly and more complex than the 
> > solution we have right now. Instead of trivial "orthogonal" polling 
> > code you are suggesting adding additional complexity - handle 
> > dynamic selection of that "master" EMAC and also handling situation 
> > when this master device goes down and you have to switch to 
> > another one without disturbing polling for other active devices. Why 
> > all this? This hw is ugly enough as it is.
> 
> Don't do dynamic selection, that indeed would be dumb.
> 
> Instead, just pick one of them to act as the polling master.
> Each EMAC has a backpointer to the master EMAC, and trigger
> the poll via that indirection.

Well, dev_close() explicitly checks and modifies state bits related 
to NAPI polling. From quick look I don't think it's safe to take down 
"master" device and expect NAPI polling to still work.

> 
> With this shared interrupt scheme and lack of hw interrupt
> mitigation, how did the designers of this chip expect people
> to do interrupt mitigation?  I suppose they expected you to
> do it by standing on your head :-)

There are more fun stuff in this hw - max buffer size is around 4080 
bytes so we have to split packets on TX and assemble on RX (meaning 
doing memcpy) for jumbo frames. You have to reset MAC on almost every 
register change, etc

-- 
Eugene

-
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