[ofw] RE: [PATCHv2] WinVerbs: Make QP modification asynchronous

[Hefty, Sean]

>The app isn't multithreaded so I ran two apps side by side:
>
>Async: 3562
>Sync: 2705

Any theories on why the async case increased so much versus your previous run?  Note that the 2-'threaded' sync case now outperforms the 1-thread async case with work items.  I'm guessing this is the cost of the context switch.

>The CPU wasn't pegged in either of these tests, so I ran again with 4 apps side
>by side...
>
>Async: 3933
>Sync: 3869

I'm surprised by this.  I would have expected the async to do worse at some point.

>Still not CPU bound, but close and I think the part that isn't CPU bound is due
>to QP creation and destruction.  It's hard to get all 4 to start at the same
>time, too, so there's a little skew between them.

As long as the test run is sufficiently long, the skew shouldn't really matter.

>> I would also like to see the results of using the work item for an
>> application that waits for the Modify to complete.  (This is how
>> libibverbs, DAPL, or an IBAL compatibility layer would use the calls.  I
>> don't think the ND provider uses the call.)
>
>You mean strict serialization?  As in move each QP through its states, destroy
>it, and only then create the next?  Don't you have a test for that at the
>libibverbs level you can use?

The libibverbs examples are higher level, stuff like ping-pong messages.  I was hoping this would be an easy change to your test app.  (E.g. pass in NULL for overlap when modifying the QP, and winverbs will do the operation synchronously.)

>Writing a test that establishes connections is significantly more complicated,
>though, and I wanted to demonstrate the benefits of the asynchronous operations
>and get buy in on that before really investing a lot of time/effort for
>something that's going to be rejected...

I don't think a test case for that will be necessary.  We can just use the results of this testing to guess what's the right thing to do.

- Sean