[EMAIL PROTECTED] wrote: > Sean Hefty wrote: >> As an update: further testing revealed that there is an issue with >> this implementation that is also found in the original code. The >> issue deals with how listen requests that rely on a data mask are >> inserted and located in the red/black tree. I'm trying to come up >> with a fix for this. > > After researching into this, I'm coming to the conclusion > that there does not exist an efficient way to sort/search for > listens without adding some restrictions. > > For example, a client listens on id1 with mask1. A request > is matched with the listen if its serviceid & mask1 = id1. > If a second client listens on id2 with mask2, then a request > must check against both requests for a match, or until a > match is found. There's no method that I can find that can > be used to filter checks that works in a generic fashion, > resulting in requests needing to walk a linear list of > listens. There are several potential fixes for this, with > only a couple mentioned below. > > One solution around this is to have the IB CM only listen on > service IDs, and remove the mask parameter from the API. > This requires SDP to change to only listen on ports that have a > listener. > > Another alternative is to restrict the type of masks that are > supported. If masks are restricted to a series of most > significant bits, then the existing algorithm can be used. > For instance, we can support masks 0xFF00 and 0xFFF0, but not > 0x00FF or 0xFF0F. This restriction would work for both SDP and the > CMA. To be clear, the API could change from a mask to the number of > bits to match. > > Matching on private data can either be done by clients, or > restrictions can be placed on it as well. For private data, > I believe that a restriction that all listen requests on the > same service ID use the same mask is sufficient. > > Hopefully this makes sense to people. Thoughts? >
Just listen on the Service ID / Port and let the ULP sort them out by destination IP address. _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
