On Tue, Oct 16, 2007 at 11:54:44AM +0800, Cathy Zhou wrote: > Eric Cheng wrote: > > >-the adding of the 'set' boolean to various functions to indicate to > > dls/mac to skip some processing if per-stream is enabled. The 'set' > > argument has no use to anything other than softmac so adding this to > > mac interfaces doesn't seem right to me (those aren't public yet > > but it's best to keep them simple). > > > What I could do is to do what VNIC does for mac_active_set() and > mac_active_shareable_set(), that is to add another function (e.g., > mac_promisc_perstream_set()) which share the same function with the current > mac_promisc_set(). >
that vnic code is getting reimplemented for crossbow so it's not a good model to follow. what I prefer is to reduce the number of special cases as much as possible, and if that can't be done, try to isolate the special cases to one area only (dld or mac). > >To address the above issues and perhaps simplify per-stream support > >further, I would like to propose a slight modification to the current > >design: > > > >1. softmac always opens a shared lower stream (smac_lower), even if > > per-stream is enabled. this lower stream is used for all non data > > dlpi messages. dld_proto.c should not need any changes except for > > the data path and DL_BIND_REQ. this stream does not need to be put > > in DL_PROMISC_SAP mode unless necessitated by certain functionality > > (vlans..etc). > > > >2. the data path stream does not need to be opened until dls_bind() > > is called. dls_bind() would call a function that does: > > a. perstream_capab.mpc_open() > > b. send DL_BIND_REQ to lower data path stream. > > b could possibly be placed inside a. > > on return from this function, dld_str_t (or dls_impl_t) should have > > whatever info necessary to access the lower data path stream. > > > >3. the softmac's mi_unicst/mi_promisc/mi_multcst entry points will > > generate DLPI messages to the shared lower stream. within dls, all > > data structures remain as before (dls_impl_t still get added to > > dl_impl_hash..etc). > > > That is basically how shared-lower-stream scheme is implemented. It sounds > like all the data messages would come from shared lower stream? How that > can be fast-path? (Note that for fast-path, the mac/dld/dls layer is almost > skipped in the data-path). > 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). > >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. > > > I don't think I get your idea. Why the promisc mode on the per-stream > stream is also turned on? > > 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. > 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. 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. eric
