[openib-general] Some Missing Features from mthca/userMADaccess

[shaharf]

Hal and Sean,
 
sorry for now responding earlier, but I was sick for few days.

		On Tue, 2005-01-11 at 12:15, Sean Hefty wrote:
		> An issue with attribute filtering is that is results in an O(lg n)
		> algorithm being used to route MADs to the correct client.  Routing
		> based on class/method can be done in O(1), since the range of
		> classes/methods is substantially smaller than that of attributes.
		>
		> Adding an attribute mask isn't overly difficult, it just wasn't felt
		> that it was necessary.
		
		Right. It was a combination of the implementation inefficiency but more
		significantly the lack of a compelling need but...
		

		

[SHAHAR] Attributes filtering can be done with O(1). First you don't have to support the entire theoretical range. Currently less then 256 attributes are used per class. I don't see this changing so fast... . Even if you want to support the entire range, you can dedicate an attribute table per class (per port) or, if the memory consumption is too big, you can use a small (open) hash table, and when taking into account that very few attributes are used in practice, you will have  O(1) algorithm. Such lookups can be made very efficient. But even more important then that, what is the use for methods filtering? Doing things just because they looks easy is very bad. Currently it seems that the entire filtering scheme is useless. Am I wrong? Does someone have a good justification for it?

		 
		Do you see a way to handle the different SA client registrations for
		events (InformInfo) where an incoming Report could go to multiple
		clients with the current approach ? Even adding attribute ID is
		insufficient as there would need to be some sense of what reports were
		being registered for (perhaps by TrapNumber but one could support even
		more granularity including ProducerType and other fields in the
		subscription (InformInfo) request).
		
		I know no OpenIB code is currently doing this, but shouldn't this be
		supported ?
		

[SHAHAR] Traps may be an unresolved issue. I guess we have to handle it, but I am not sure that umad based filtering is the correct mechanism. Surely, there is no justification to give up the copy less approach and to switch over to completely copy full approach (i.e. snooping) just for the corner cases. This is not how you achieve optimized systems. You have to keep your main paths very optimized, and handle your corner cases in other mechanism that may be less optimized. For example, we can implement some sort of traps filtering in the umad library. Not everything must be in the kernel. Lean and mean, isn't it the approach (at least in the kernel)?

 

Shahar