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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
