> > On Tue, Jan 23, 2018 at 11:24:24AM -0600, Steve Wise wrote: > > > > > > On Tue, Jan 23, 2018 at 10:58:01AM -0600, Steve Wise wrote: > > > > > > > From: https://tools.ietf.org/html/rfc5041#section-5.2 > > > > > > > > "At the Data Source, the DDP layer MUST segment the data contained in > > > > a ULP message into a series of DDP Segments, where each DDP Segment > > > > contains a DDP Header and ULP Payload, and MUST be no larger than the > > > > MULPDU value Advertised by the LLP." > > > > > > > > Where MULDPDU is the maximum ULP PDU that will fit in the TCP MSS... > > > > > > But exceeding the MULPDU has nothing to do with the netstack GSO > > > function.. right? GSO is entirely a local node optimization that > > > should not be detectable on the wire. > > > > It is not detectable by TCP on the wire, however the iWARP protocols that > > impose message boundaries, among other things, require that the iWARP PDU > > fits in a single TCP segment. Since softiwarp is building the iwarp PDU, if > > it builds one based on a 64K GSO advertised MSS, then the resulting wire > > packets will have man TCP segments all containing parts of a single iWARP > > PDU, which violates the spec I quoted. > > But that still has nothing to do with GSO, can't you GSS up to MULPDU? > I don't understand your question. > Isn't the issue here more that, as Bernard says, siw is totally broken > since it can't control the TCP layer segmentation boundaries? :( > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html