[openib-general][PATCH] mthca & ib_verbs.h client reregister event support

Leonid Arsh leonida at voltaire.com
Sun Apr 2 07:10:55 PDT 2006


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 <leonida at voltaire.com>:
>   
>> 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.
>
>
>   




More information about the general mailing list