netdev - Re: [PATCH RFX]: napi

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: <1185326149.1803.421.camel@localhost.localdomain>
Date:	Wed, 25 Jul 2007 11:15:49 +1000
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org, shemminger@...ux-foundation.org,
	jgarzik@...ox.com, hadi@...erus.ca
Subject: Re: [PATCH RFX]: napi_struct V3

On Tue, 2007-07-24 at 17:45 -0700, David Miller wrote:
> I'm now going to go over the other resched cases and make sure
> things can be similarly handled in those drivers as well.
> To be honest I'm quite confident this will be the case.

If I understand correctly, you're looking at a general model like the
following:

	while (more_packets()) { ... netif_receive_skb() }

	enable_rx_and_rxnobuf_ints();

	/* Lock protects against race w/ rx interrupt re-queueing us */
	spin_lock_irq();
	if (!more_packets())
		netif_rx_complete(dev);
	else
		/* We'll be scheduled again. */
		disable_rx_and_rxnobuff_ints();
	spin_unlock_irq();

Seems pretty robust to me.  The race is probably pretty unusual, so the
only downside is the locking overhead?  Even non-irq-problematic drivers
could use this (ie. virt_net.c probably wants to do it even though
virtio implementation may not have this issue).

Cheers,
Rusty.

-
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