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]

Message-ID: <20061207094502.GA19479@gate.ebshome.net>
Date:	Thu, 7 Dec 2006 01:45:02 -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:16:27AM -0800, David Miller wrote:
> From: Benjamin Herrenschmidt <benh@...nel.crashing.org>
> Date: Thu, 07 Dec 2006 15:24:06 +1100
> 
> > 
> > > What Eugene does currently, which seems to me like it's actually the
> > > only proper solution, is to create a separate net_device structure for
> > > the DMA engine and thus have a single NAPI poll & weighting for all the
> > > EMACs sharing a given MAL (MAL is the name of that DMA engine). This
> > > means that Rx from any of the channels schedules the poll, and
> > > interrupts can be properly masked/unmasked globally based on the
> > > presence/absence of work on all the channels.
> > 
> > Actually, another solution would be to have one of the instances do the
> > NAPI poll for all of them instead of creating a separate net_device for
> > the DMA engine...
> 
> I think this idea would work the best.

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.

> Just link the other related devices into a list in the driver private
> struct.  Or a simple "work pending" bitmask for each of the EMACs,
> which tell the primary EMAC netdev which devices should be polled.
> 
> This architecture doesn't make things easy, that's for sure :-)
> 
> If things get too hairy, don't feel too bad about ideas like forgoing
> NAPI altogether and just using the interrupt mitigation features of
> the chip.  Does it have any?

No, it does not.

-- 
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