Yes, I agree with you about your preference to have a software solution,
but the actual ClientReregister request handling is done by the FW,
isn't it?
If so, it can be a kind of mixture between SW and HW anyway.
As to the bit setting in the mthca_set_mad for old FW, it is not enough,
since the actual request handling would not be done.
We'll have to add the request handling to the SW too. But why should we,
if the new FW excellently does it?
It also generates an event for us.
I like the approach to handle as much as possible in SW,
but for my opinion both ways are acceptable in our case.
Michael S. Tsirkin wrote:
Quoting r. Leonid Arsh <[EMAIL PROTECTED]>:
Subject: Re: [openib-general][PATCH] mthca & ib_verbs.h client reregister event
support
Michael,
the event is quite rare, so I see no risk for the event queue.
I also think that using the HW event is a bit more elegant, so I
implemented it like in the VAPI based driver.
No idea why VAPI did it this way: I personally prefer software solutions since
they are so much easier to debug.
The new FW generates the event in any case, and we just add a compact
event handler.
Only smp_snoop() on the older FW will not help, since the older FW
doesn't set the ClientReregistration port capability bit automatically,
so the SM will not generate ClientReregistrer requests.
Looks like you'll just need to set this bit in mthca_process_mad. No?
There is a way
to set the bit by the SW, but it would add some redundant complexity.
There need not be any redundancy: I don't advocate using both the software and
hardware-based mechanism: let's just handle this even from smp_snoop and be done
with it.
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
