>> 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. >> > > I think today in nemo we have a MAC_NOTE_UNICST that updates the mac > address of every dld_str_t/dls_impl_t. I know we can't assume the same > for dlpi drivers so I think mi_unicst() should just send > DL_SET_PHYS_ADDR_REQ down every data path stream and the shared stream. > >> Also, DLIOCRAW and DLIOCHDRINFO would be processes by both streams. Is >> that right? >> > > unfortunately yes. these would have to be sent down both streams. > so on rx, it might be possible for an upper stream to get an M_DATA > packet (with or without header) even though it did not ask for DLIOCRAW > or DLIOCHDRINFO. in this case we would have to strip the header or > construct a DL_UNITDATA_IND. > For the above, I think we agreed the same thing.
>> 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. >> > initially the data stream is the only stream that can receive packets > (unicast + broadcast) since it's bound to a particular sap (e.g. IP). > the shared stream is not bound so it cannot receive anything. > Assume that there is a per-stream DLS stream, and another MAC client that requires the shared lower stream to be bound to a sap (for example, an aggregation is created over this MAC), does that mean the performance of the per-stream DLS stream would also suffer from this? Further, in this case, whether or not to filter out the duplicated messages depends not only on the state of the stream itself, but also the existence of other MAC clients. This does not seem right. > if a upper stream issues a DL_ENABMULTI_REQ, this is when we have to > bind the shared stream as well since we want multicast packets to go up > the shared stream. but what sap do we bind to? it probably doesn't > matter because we would have to turn on DL_PROMISC_SAP on the shared > stream in order to get all multicast packets (not just ones destined to > a particular sap). > Note that any upper stream which has DL_ENABMULTI_REQed, would cause the shared stream to be bound to a SAP, and this would influence other upper streams (to do the duplicate message drop). > now we have two streams ready to receive data: > data stream would receive unicast + broadcast packets. > shared stream would recieve unicast + multicast + broadcast packets. > > both streams would enter softmac_rput() before nemo so some filtering > could be done at that point. we could make unicast packets go only to > the data path stream (via rxinfo->mpr_rx()) and broadcast + multicast go > only to the shared stream (via mac_rx()). the check should require > comparing only one byte. > This one-byte comparison assumes Ethernet media type, right? >> 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). > > supposing we do not turn on DL_PROMISC_PHYS on the lower stream (more > later), why does dls_accept() need to change if we filter early in > softmac as I mentioned above? dls_accept() will compare the > per-dls_impl_t multicast list anyway so filtering is already being done. > >> 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. >> > > from mac and above, the performance impact is mostly likely small. what > I am worried is what happens in the dlpi driver if we turn on > DLS_PROMISC_SAP. If I remember correctly ce does dupmsg() when passing a > packet up multiple streams right? That is correct. But my concern is mostly that assume there is aggregations created over this MAC, or there is one upper stream is set to promiscuous mode, which would affect other upper stream's performance significantly. > if that's the case there shouldn't be > much copying overhead. > >> 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. >> > the filtering could be done in softmac as explained above. > >> If the promiscuous mode is set, something similar would be done for >> the shared-lower stream to filter out the duplicated messages. >> > > to support DL_PROMISC_PHYS properly and at the same time get good data > path performance might be hard. do you think it's ok to degrade data > path performance when there are snoop streams open? if we can make this > assumption we could just drop all packets coming from data path streams > and let the demultiplexing get done properly by mac_rx() -> > i_dls_link_rx_promisc() when packets arrive from the shared stream. > >> 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). > > I don't fully understand your tx path yet so I can't comment on how to > do the flow control. but if I read the code correctly, when someone is > snooping, the tx path doesn't really go through mac_txloop() but > actually go does down to the dlpi driver and comes back up, right? That is correct. > also, I noticed you added a new function dld_wput_perstream_callback() > and similar putnext() code in dld_wsrv(). the reason you do this here > instead of within softmac_m_tx() is because you can't pass down the the > lower stream write queue, right? dld_wput_perstream_callback() is for the per-stream scheme upperstream, (which is the fast-path), and we don't do softmac_m_tx() is that we'd like to skip MAC layer completely in that case, so neither mac_tx(), or mac_txloop() is called in that case. > if that's true, I think this is the > right time to add a third argument to mi_tx(). crossbow will be adding > that to support multiple tx channels. you can add this now to pass down > the lower write queue. if this is done, the code within > dld_wput_perstream_callback() could be moved to softmac_m_tx() and the > code in dld_wsrv() could be removed, and mac_txloop() would work just > like other drivers. > See above. >>>>> 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? >> > the data path stream is bound to a particular sap so it would only get > unicast + broadcast packets destined to this sap. whereas the shared > stream could have DL_PROMISC_* turned on and receive all packets sent to > the data path stream + everything else. > >> 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). >> > > if you are willing to sacrifice data path performance when there are > snoop streams open (as mentioned above), then no filtering needs to be > done. we just blindly drop everything coming up from data path streams. > At this point. I think I get your point, that you'd like to switch between the share-lower-scheme and per-stream-scheme depends the state of the upper stream (whether the stream is in promiscuous mode or DL_ENABMULTI_REQ is sent). What I don't agree is that the scheme selection would be affected by the state of other upper streams as well. > as suggested above, softmac would do the filtering: > -broadcast packets would be dropped from all data streams > -multicast packets would come up only from the shared stream (since we > do not add multicast addresses to data streams) > -unicast packets would be dropped from the shared stream > >> 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. >> > > I think we had a good discussion here. so even if you don't do this now > due to time constraints, I think we have enough material to warrant some > post-putback work. > True. We could have some work done post-putback, once we are clear about every problem we discussed here. Thanks - Cathy > eric > >>> 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 >> >> >> _________________________________ >> clearview-discuss mailing list >> clearview-discuss at opensolaris.org >
