Eric Cheng wrote: > On Fri, Aug 14, 2009 at 01:29:53AM -0700, Peter Memishian wrote: >> > > So what is the intended purpose of mci_name? Clearly it is not to >> uniquely >> > > identify an object. >> > >> > right now there is a kstat and flow name that's tied with this. all of >> > these get renamed together. as long as the mac client doesn't call >> > mac_unicast_add(), the kstat won't be created. the flow name doesn't >> > matter since this is an internal, not user-defined, flow. >> >> This seems pretty fragile -- e.g., it is not at all obvious that >> introducing a mac_unicast_add() call can cause kstat problems because >> of previously-overlapping mac client names. Also, if the flow name >> doesn't matter, why are we assigning a name at all? >> > > the flow name is there because it will be used for creating the kstat > in case mac_unicast_add() gets called. yes, this sounds a bit convoluted. > > (the code is: > mac_client_open()->mac_flow_create() creates an empty flow > at some point later mac_unicast_add()->mac_client_datapath_setup()->... > mac_flow_create() is called again to create the kstat)
This may no longer be the case in the near future. BPF can send packets, and these packets should be accounted by dlstat(1M) when it displays per MAC-client statistics. So we will have to maintain statistics which are derived from the MAC client name, which could conflict with the dls client if simply using MAC_OPEN_FLAGS_USE_DATALINK_NAME. >> It also seems odd that this name is serving double-duty, as it's >> alternately either provided by the consumer of the client API or set by >> mac_client_open() to something that may be of interest to the consumer >> (such as the associated datalink). One alternative would be to have the >> name always identify the consumer (mci_client_user or whatever) and have >> mci_name always identify the associated datalink, and internally use the >> concatenation of mci_client_user and mci_name name the various related >> objects like kstats and flows. >> > > sounds like this could work. +1 Nicolas.
