Messages in this thread | | | Date | Tue, 19 Oct 2004 15:42:49 -0700 | From | "David S. Miller" <> | Subject | Re: tun.c patch to fix "smp_processor_id() in preemptible code" |
| |
On Tue, 19 Oct 2004 18:42:11 -0400 Lee Revell <rlrevell@joe-job.com> wrote:
> On Tue, 2004-10-19 at 18:33, David S. Miller wrote: > > On Tue, 19 Oct 2004 18:10:58 -0400 > > Lee Revell <rlrevell@joe-job.com> wrote: > > > > > /* > > > * Since receiving is always initiated from a tasklet (in iucv.c), > > > * we must use netif_rx_ni() instead of netif_rx() > > > */ > > > > > > This implies that the author thought it was a matter of correctness to > > > use netif_rx_ni vs. netif_rx. But it looks like the only difference is > > > that the former sacrifices preempt-safety for performance. > > > > You can't really delete netif_rx_ni(), so if there is a preemptability > > issue, just add the necessary preemption protection around the softirq > > checks. > > > > Why not? AIUI the only valid reason to use preempt_disable/enable is in > the case of per-CPU data. This is not "real" per-CPU data, it's a > performance hack. Therefore it would be incorrect to add the preemption > protection, the fix is not to manually call do_softirq but to let the > softirq run by the normal mechanism. > > Am I missing something?
In code paths where netif_rx_ni() is called, there is not a softirq return path check, which is why it is checked here.
Theoretically, if you remove the check, softirq processing can be deferred indefinitely.
What I'm saying, therefore, is that netif_rx_ni() it not just a performance hack, it is necessary for correctness as well. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |