On Mon, 21 Nov 2005 22:42:29 +0100
Aritz Bastida <[EMAIL PROTECTED]> wrote:

> I have just subscribed to netdev. I used to write in the linux-net
> mailing list, but there is little activity in there.
> 
> 
> > >
> > > What I need is to turn off and on the polling done to a network device
> > > which works with NAPI. I'll explain: the network driver issues
> > > netif_rx_schedule() and inserts itself in that cpu's poll_list. But,
> > > transparently, in higher-layer kernel code, that device could be
> > > extracted from that poll_list (if the machine is in congestion, that's
> > > the research i'm doing) and added again later.
> >
> > Unless that higher-level code is on the same CPU, you will have introduced
> > a race.
> 
> When do you mean there is a race? If I call netif_rx_complete() in
> higher-layer kernel code to remove the device from the poll list, and
> activate it later on calling netif_rx_schedule()  (outside of the
> driver), would it work? Of course, in this case, the scheduled softirq
> could run in a different cpu from the one it was executing before
> deactivating it. But, in this case, there wouldn't be a race, and it
> would work properly right?

If the higher level is not on the same CPU there is race when the
poll routine is running. Kind of like the timer race that del_timer_sync()
solves.

> Now, if I want that the scheduled softirq runs in the same cpu as the
> previous, I would probably need to access another processors
> softnet_data struct, which would be racy. Is that what you mean?

Yes, you can access it but you don't know what state the scheduled
poll is in, is it running or not?


> Anyway, if I use the functions above, which in theory should be used
> by drivers (netif_rx_schedule in hardware interrupt, and
> netif_rx_complete in poll function), but I use them for my own
> purposes in higher level code, all would work right?
> 

Read del_timer_sync() and do something similar.

-- 
Stephen Hemminger <[EMAIL PROTECTED]>
OSDL http://developer.osdl.org/~shemminger
-
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

Reply via email to