Nicolas Droux writes: > - We already talked about having more common MAC hooks that would > allow consumers like bridging and L2 filtering intercept and inject > packets without having to change the common data-path. I'll start > defining those soon.
OK. > - For the RX path you need to handle the poll path as well or you will > miss packets, see mac_rx_srs_poll_ring(). I didn't see that covered in > your design doc or code. mac_rx() covers the interrupt path only. Good point. Thanks for the reference. It took a while, but I was able to reverse-engineer a good bit of that code path. (I don't know of a design document that covers this; my sparse notes in case anyone is interested are below.) It seems that the right place to hook this is in mac_rx_srs_drain and mac_rx_srs_drain_bw, at approximately the same point they do the mac_promisc_client_dispatch. I don't want to mess with the polling functions up above. Given the context (the fact that a bridge can make input packets look like they came from a different underlying mac), I think the right thing to do is to let the bridge process the packets and continue deliverly up through mac_bridge_rx and the software classifier. > BTW > this is another example why generic MAC hooks would be useful to have, > i.e. you wouldn't have to deal with all the details of the data-path. Yes. > - For the TX path we're going to modify the TX default processing to > use a fanout of rings instead of a single default TX ring to better > scale. So some of the changes you are making related to the TX entry > points would have to be redone. It would be better to not have the > callers specify the default TX ring. Agreed; I think the simpler way would be to have a single mac_tx function that knows how to deal with rings when necessary. Code exploration notes: mac_rx_srs_poll_ring puts input packets on the srs_first/srs_last queue, and srs_drain_func processes the packets. That pointer may be either mac_rx_srs_drain or mac_rx_srs_drain_bw. Both of those functions end up calling sr_func, mac_rx_srs_fanout, or mac_rx_srs_proto_fanout to deliver the packet. The sr_func pointer is set by mac_srs_create and mac_srs_change_upcall. mac_srs_create is called only by mac_srs_group_setup, which passes mac_rx_deliver as the sr_func callback. Nobody ever calls mac_srs_change_upcall (!). This means that sr_func is always just mac_rx_deliver. Both mac_rx_srs_fanout and mac_rx_srs_proto_fanout call mac_rx_soft_ring_process, which calls s_ring_rx_func or mac_soft_ring_worker_wakeup. The latter wakes up mac_soft_ring_worker, which calls s_ring_drain_func. s_ring_drain_func is set only by mac_soft_ring_create, and is always set to mac_rx_soft_ring_drain, which ends up calling through s_ring_rx_func. Thus, s_ring_rx_func is the only path. s_ring_rx_func is set by mac_soft_ring_create, mac_soft_ring_dls_bypass, and mac_srs_client_poll_disable. mac_srs_client_poll_disable sets s_ring_tx_func to mac_rx_deliver. mac_soft_ring_create is called by mac_srs_create_proto_softrings, which is called by mac_srs_fanout_modify and mac_srs_fanout_init. mac_srs_fanout_init and mac_srs_fanout_modify are called by only mac_fanout_setup. All callers of mac_fanout_setup pass in mac_rx_deliver as the receive function. The only path that mac_soft_ring_create can currently use is mac_rx_deliver. mac_soft_ring_dls_bypass is thus the only current thing that can set an upward direction different from mac_rx_deliver, and it seems to be called from mac_srs_client_poll_enable, which in turn is called by mac_client_poll_enable, called by dld_capab_poll_enable. -- James Carlson, Solaris Networking <[email protected]> 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 _______________________________________________ networking-discuss mailing list [email protected]
