Its via the macro MAC_SRS_POLLING_ON(). And mac_rx_srs_drain is the only one that can cause the link to go into poll mode and that happens only if a backlog builds up i.e srs_rx->sr_poll_pkt_cnt > 0 after we are done draining all packets. Also worth noting is that interrupt path (mac_rx_srs_process) also calls mac_rx_srs_drain() to process the packets and mac_rx_srs_drain is the common function where processing starts (doesn't matter if packets come via interrupt or poll path).
HTH, Sunay On 04/03/09 13:18, James Carlson wrote: > I'm trying to test out some changes related to mac_rx_srs_poll_ring() > and bridging, and since I can't currently generate enough traffic > (reliably) to trigger anything special to happen, I'm trying to > understand the mechanism behind polling mode to see if I can 'force' > an interface into that mode briefly for testing. > > It seems that mac_rx_srs_poll_ring(), the main polling thread, blocks > waiting on srs_cv. The functions that can signal that cv are: > > mac_srs_signal > mac_srs_worker_restart > mac_rx_srs_drain (via MAC_SRS_POLL_RING) > mac_rx_srs_drain_bw (via MAC_SRS_POLL_RING) > various (via MAC_UPDATE_SRS_COUNT_LOCKED) > > The first two are used only during quiesce, and the drain functions > are used only when already polling, so that leaves the last one. But > the MAC_UPDATE_SRS_COUNT_LOCKED macro checks for SRS_POLLING first. > The only things that can set that flag are: > > mac_rx_srs_drain (via MAC_SRS_POLLING_ON) > mac_rx_srs_drain_bw (via MAC_SRS_POLLING_ON and > MAC_SRS_WORKER_POLLING_ON) > > and the trail gets cold right there. So what sets SRS_POLLING in > order to allow MAC_UPDATE_SRS_COUNT_LOCKED to signal the polling > thread? How exactly do we get from interrupt mode to polling mode? >
