[ofw] RE: Release IBA resources in DISPATCH_LEVEL ?

[Leonid Keller]

Hi Fab,
I didn't tell that there are HW limitations.
I meant to say that in addition to the change of CMD interface API and
IBAL one have to add all the logic of issueing/delaying of requests,
which make the things more complicated.
Maybe it was obvious to you.  :(

> -----Original Message-----
> From: Fab Tillier [mailto:ftillier at windows.microsoft.com] 
> Sent: Monday, June 16, 2008 1:25 AM
> To: Leonid Keller; Tzachi Dar; Sean Hefty; James Yang; 
> ofw at lists.openfabrics.org
> Subject: RE: [ofw] RE: Release IBA resources in DISPATCH_LEVEL ?
> 
> Hi Leo,
> 
> > -----Original Message-----
> > From: Leonid Keller [mailto:leonid at mellanox.co.il]
> > Sent: Sunday, June 15, 2008 2:08 AM
> >
> >> The only reason waiting is needed is because the driver 
> >> implementation forces it.
> > Generally, you are right, but it's a bit more complicated 
> then that. 
> > There are dependencies between the commands, which can 
> cause problems 
> > in fully asynchronous work with the card.
> 
> I disagree: the blocking semantics are independent of 
> hardware limitations.
> 
> Dependencies between commands just affects whether you can 
> issue the command right away, of if you have to wait for a 
> previous command to complete.  You need that anyway as the 
> hardware has a limit to the number of commands that it can 
> handle concurrently, even with the synchronous mechanisms in 
> use today.  With the synchronous model of the driver, you may 
> block before the command is issued, and you will block while 
> the command is being processed by the hardware.  The logic 
> must already be there to resume command processing when a 
> command completes, regardless of whether the command is 
> blocking or asynchronous.
> 
> With an asynchronous model, the caller's request would always 
> return STATUS_PENDING.  It would do this when either
>   a). a command is in progress that is a prerequisiste for 
> this command;
>   b). there are too many commands in flight to issue this command;
>   c). the command is issued to the hardware;
> 
> For cases a) and b), the command would be issued once the 
> prerequisite command or first previous command completes, 
> respectively.
> 
> In all cases, the client would be notified of the request 
> completion when the command is complete.
> 
> I would actually suspect handling commands asynchronously 
> would simplify the HCA driver.  All the logic for blocking 
> and waking up the caller would be eliminated.  The HCA driver 
> wouldn't have to care whether callers are at DISPATCH or 
> lower, the processing would be the same always.
> 
> -Fab
> 


--
Leonid Keller
Mellanox Technologies LTD.
SW- Windows
Phone: +972 (4) 909 7200 (ext 372)
Mobile: +972 (54) 464 7702
E-mail: leonid at mellanox.co.il

----------------------------------------------------------------------
Emails belong on computers, trees belong in forests; if you must print
this, do it on recycled paper.
http://www.greenpeace.org/international/
----------------------------------------------------------------------


Disclaimer added by CodeTwo Exchange Rules
http://www.codetwo.com