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?
--
James Carlson, Solaris Networking <james.d.carlson at
sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
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? >
Sunay Tripathi writes:> packets. Also worth noting is that interrupt path > (mac_rx_srs_process) also calls mac_rx_srs_drain() toAh, ok, that''s the key part I was missing here. I had expected that mac_rx_srs_drain was only called as part of the polling thread. Thanks. -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677