> I am suggesting to use 2 streams. the shared lower stream will be used for > passing down all dlpi control messages from all upper streams. this shared > stream will be opened at dld_str_attach() time. when a upper stream sends a > DL_BIND_REQ, this is when the 2nd lower stream (data path) is opened and > bound to the specified sap. the upper stream would also exchange perstream > info (rx/tx pointers) with the newly opened lower stream. > > so far we have: > -a data path stream bound to a sap, it can send/receive data directly > to/from dld. > -a shared stream that's open but not ready to use since nothing has been > sent to it yet. > > now, suppose we send a dlpi control message from the upper stream to nemo, > nemo > intercepts it and calls a mi_promisc/unicst/multicst entry point instead which > would in turn send a corresponding dlpi message down the *shared* lower > stream. > > the primitives listed above mostly affects shared mac state so its not that > important which stream they get sent down from. if one (out of many) upper > streams turns on promisc mode, the shared stream would start receiving > packets as well. i_dls_link_rx_promisc() should do the right demultiplexing > there. it could be made to pass packets only to promisc mode upper streams and > drop everything else (because those would get passed up the data path > lower stream instead). > [ As I'd like to see the possibility of the change, below I am just thinking loudly. Please point me out if I am wrong. ]
First, I think mi_unicst() has to be known by the data-path-stream, so that the change of the unicast address wouldn't make that stream not be able to receive any packets. Also, DLIOCRAW and DLIOCHDRINFO would be processes by both streams. Is that right? Leave that aside, if I understand correctly, "normal" packets would be send/received from the data-path-stream, and "special" packets (received because of the promiscuity-mode or the multicast packets) would be received from the shared-lower-stream. That means every packets would go through both streams, and we would need to change dls_accept() function and filter out the duplicated messages (the policy to decide whether or not pass up to the DLS clients would become complicated, see more below). At this point, without prototype, I am not sure whether it can be done. The first concern I have is the performance impact it may bring. Let's give an example, assume this is a softmac whose mac address is U1, and the DLS client requests to add a multicast address M1. The broadcast address is B1. Two lower streams would be set up - shared stream SS and data path stream SD. On the receive side, packets of destination U1, M1, B1 would all be passed to SS and in turn the i_dls_link_rx() function, and packets of dest U1, B1 would also be passed to SD. We would filter out the U1, B1 packets in SS to avoid duplicated messages. If the promiscuous mode is set, something similar would be done for the shared-lower stream to filter out the duplicated messages. On the tx side, some special handling would also be needed. The packets would be sent out either through the data-path-stream (normal case) or the shared-lower-stream (promiscous mode case). We need to take great care, which one to use, and especially when to qenable() the queue so dld_wsrv() would be called. (Note that softmac_wsrv() of both lower streams might ultimately result in a dld_wsrv(), an incorrect qenable() might cause the packets disordering). > >>> 4. when promisc mode is turned on, packets will get delivered to both >>> the data path stream (bound to a particular sap) and the shared lower >>> stream. to prevent getting duplicate data, i_dls_link_rx_promisc() >>> could be made to pass packets only to dls_impl_t's bound to >>> DLS_PROMISC_SAP and drop everything else when there exists a separate >>> lower data path stream. >>> In another mail, you said the promiscuous mode is not turned on the data-path-stream. Then how the packets can get delivered to both streams? If the promiscuous mode is turned on the data-path-stream, see above, i_dls_link_rx_promsic() would have decode/compare each packets and pass up all packets except those are destined to the MAC address (and the broadcast address). >> How about those multicst/broadcst packets? Do they come up from both >> streams too? > > yes. they get passed up both streams. and the promisc mode shared stream > would drop them. > Again. See above. >> My current implementation basically follows the principle that shared >> stream and per-stream stream are separated and serve for different purpose. >> So they are independent from each other. Your proposal sounds more >> complicated than that. But maybe I mis-understood your idea. >> > yes. I agree it's more complicated. but if the complication could make > per-stream impact nemo less, or at least confine per-stream related code > further, I think that's a good trade off. > Understood. But complication means it is more error-prone. Since this is the late phase of the project, I also feel uncomfortable to make such a major change. But I am still willing to make the changes, if the discussion turns out this is a cleaner design. > again, I am not insisting that this has to be done. I just want you to > think through a bit whether doing this is worthwhile or not. There could > be some cases that I missed that make this infeasible. > Thanks - Cathy
