RE: [PATCH v3 03/13] Attach/detach SoftiWarp to/from network and RDMA subsystem

Bernard Metzler
2018-01-23T18:21:49Z

-----"Steve Wise" <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org> wrote: -----

>To: "'Jason Gunthorpe'" <jgg-uk2M96/98Pc@public.gmane.org>
>From: "Steve Wise" <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
>Date: 01/23/2018 06:55PM
>Cc: "'Bernard Metzler'" <bmt-OA+xvbQnYDHMbYB6QlFGEg@public.gmane.org>,
><linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
>Subject: RE: [PATCH v3 03/13] Attach/detach SoftiWarp to/from network
>and RDMA subsystem
>
>>
>> On Tue, Jan 23, 2018 at 11:42:20AM -0600, Steve Wise wrote:
>>
>> > Since the iwarp protocols run on top of TCP/IP, there is always
>the case
>> > that some middle box resegments tcp segments differently, so a
>good
>iwarp
>> HW
>> > implementation should deal with funny alignments, partial iWARP
>PDUs
>> > arriving, etc. But the RFCs, as I read them, want
>implementations to
>try
>> > "really hard" to avoid spanning an iWARP PDU across many TCP
>segments.
>> And
>> > I think siw should do the same, by default.
>>
>> But Bernard just said siw doesn't interoperate in certain cases
>> because of this - so that sounds like more than 'try really hard'
>??
>>
>> Or is that an overstatement and it just makes the rx side slower if
>> segmentation is not optimal?
>
>Creating 64K iWARP PDUs causes interoperability problems. If siw
>builds
>iWARP PDUs that fit within the TCP wire MSS, then these problems are
>avoided, and siw becomes more spec compliant. If the iWARP PDUs are
>built
>this way, then nothing the tcp stack does will cause problems other
>than
>slow down things.
>
Right. It's just the slowdown what hurts me. But it may improve the
need to buy real iWarp HW for good performance ;)

See, I came for the other side looking at that - how to make best
use of kernel services, if I anyway cannot completely control the wire
shape of the frames I push. But I understand that some HW cannot
deal with it.

Same is true for small messages. if siw puts one 8 byte payload packet
in one TCP frame, we end up with 350k IOPs. If we allow to pull
multiple of it into one frame, if the send queue has more work to do,
it goes much higher, and we avoid much extra delay.
I recently removed that optimization, just to avoid discussion on it.