Re: [PATCH RFX]: napi_struct V3

[Rusty Russell <rusty@rustcorp.com.au>]

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.