From: "Steve Wise" <swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
To: 'Jason Gunthorpe' <jgg-uk2M96/98Pc@public.gmane.org>
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
Date: Tue, 23 Jan 2018 11:24:24 -0600 [thread overview]
Message-ID: <013a01d3946f$034683f0$09d38bd0$@opengridcomputing.com> (raw)
In-Reply-To: <20180123170517.GE30670-uk2M96/98Pc@public.gmane.org>
>
> 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.
>
> > > > Jason, would configfs be a reasonable way to allow tweaking these
> > globals?
> > >
> > > Why would we ever even bother to support a mode that is non-conformant
> > > on the wire? Just remove it..
> >
> > For soft iwarp, the throughput is greatly increased with allowing these
> > iWARP protocol PDUs to span many TCP segments. So there could be an
> > argument for leaving it as a knob for soft iwarp <-> soft iwarp
> > configurations. But IMO it needs to default to RFC compliance and
> > interoperability with hw implementations.
>
> IMHO the purpose of things like rxe and siw is not maximum raw
> performance (certainly not during the initial kernel accept phase),
I agree.
> so
> it should not include any non-conformant cruft..
>
IMO leaving it as a non-default-enabled knob is ok in this case.
Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2018-01-23 17:24 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-14 22:35 [PATCH v3 00/13] Request for Comments on SoftiWarp Bernard Metzler
[not found] ` <20180114223603.19961-1-bmt-OA+xvbQnYDHMbYB6QlFGEg@public.gmane.org>
2018-01-14 22:35 ` [PATCH v3 01/13] iWARP wire packet format definition Bernard Metzler
2018-01-14 22:35 ` [PATCH v3 02/13] Main SoftiWarp include file Bernard Metzler
2018-01-14 22:35 ` [PATCH v3 03/13] Attach/detach SoftiWarp to/from network and RDMA subsystem Bernard Metzler
[not found] ` <20180114223603.19961-4-bmt-OA+xvbQnYDHMbYB6QlFGEg@public.gmane.org>
2018-01-23 16:33 ` Steve Wise
2018-01-23 16:43 ` Jason Gunthorpe
[not found] ` <20180123164316.GC30670-uk2M96/98Pc@public.gmane.org>
2018-01-23 16:58 ` Steve Wise
2018-01-23 17:05 ` Jason Gunthorpe
[not found] ` <20180123170517.GE30670-uk2M96/98Pc@public.gmane.org>
2018-01-23 17:24 ` Steve Wise [this message]
2018-01-23 17:28 ` Jason Gunthorpe
[not found] ` <20180123172830.GF30670-uk2M96/98Pc@public.gmane.org>
2018-01-23 17:39 ` Bernard Metzler
2018-01-23 17:42 ` Steve Wise
2018-01-23 17:47 ` Jason Gunthorpe
[not found] ` <20180123174758.GH30670-uk2M96/98Pc@public.gmane.org>
2018-01-23 17:55 ` Steve Wise
2018-01-23 18:21 ` Bernard Metzler
2018-01-23 17:23 ` Bernard Metzler
[not found] ` <OF34749881.4216E578-ON0025821E.005F897C-0025821E.005F8983-8eTO7WVQ4XIsd+ienQ86orlN3bxYEBpz@public.gmane.org>
2018-01-23 17:43 ` Steve Wise
2018-01-23 17:21 ` Bernard Metzler
2018-01-14 22:35 ` [PATCH v3 04/13] SoftiWarp object management Bernard Metzler
2018-01-14 22:35 ` [PATCH v3 05/13] SoftiWarp application interface Bernard Metzler
[not found] ` <20180114223603.19961-6-bmt-OA+xvbQnYDHMbYB6QlFGEg@public.gmane.org>
2018-01-23 17:18 ` Steve Wise
2018-01-23 18:07 ` Bernard Metzler
[not found] ` <OF7390EC15.6C2741F2-ON0025821E.0062D222-0025821E.00639402-8eTO7WVQ4XIsd+ienQ86orlN3bxYEBpz@public.gmane.org>
2018-01-23 18:12 ` Steve Wise
2018-01-14 22:35 ` [PATCH v3 06/13] SoftiWarp connection management Bernard Metzler
[not found] ` <20180114223603.19961-7-bmt-OA+xvbQnYDHMbYB6QlFGEg@public.gmane.org>
2018-01-30 21:27 ` Steve Wise
2018-01-31 17:28 ` Bernard Metzler
2018-01-14 22:35 ` [PATCH v3 07/13] SoftiWarp application buffer management Bernard Metzler
2018-01-14 22:35 ` [PATCH v3 08/13] SoftiWarp Queue Pair methods Bernard Metzler
2018-01-14 22:35 ` [PATCH v3 09/13] SoftiWarp transmit path Bernard Metzler
2018-01-14 22:36 ` [PATCH v3 10/13] SoftiWarp receive path Bernard Metzler
2018-01-14 22:36 ` [PATCH v3 11/13] SoftiWarp Completion Queue methods Bernard Metzler
2018-01-14 22:36 ` [PATCH v3 12/13] SoftiWarp debugging code Bernard Metzler
2018-01-14 22:36 ` [PATCH v3 13/13] Add SoftiWarp to kernel build environment Bernard Metzler
2018-01-17 16:07 ` [PATCH v3 00/13] Request for Comments on SoftiWarp Steve Wise
2018-01-18 7:29 ` Leon Romanovsky
[not found] ` <20180118072958.GW13639-U/DQcQFIOTAAJjI8aNfphQ@public.gmane.org>
2018-01-18 17:03 ` Bernard Metzler
[not found] ` <OFC86A1EC5.60F00E9A-ON00258219.005DA6A4-00258219.005DBBB9-8eTO7WVQ4XIsd+ienQ86orlN3bxYEBpz@public.gmane.org>
2018-01-18 21:52 ` Steve Wise
2018-01-23 17:31 ` Bernard Metzler
2018-02-02 14:37 ` Bernard Metzler
[not found] ` <OFD1018BEE.35589194-ON00258228.00505F2B-00258228.00505F31-8eTO7WVQ4XIsd+ienQ86orlN3bxYEBpz@public.gmane.org>
2018-02-02 18:56 ` Jason Gunthorpe
[not found] ` <20180202185640.GC9080-uk2M96/98Pc@public.gmane.org>
2018-02-04 20:08 ` Bernard Metzler
[not found] ` <OFEF72EEE6.7E5C3FA5-ON0025822A.005B18E4-0025822A.006EA4BB-8eTO7WVQ4XIsd+ienQ86orlN3bxYEBpz@public.gmane.org>
2018-02-04 20:39 ` Jason Gunthorpe
2018-01-23 16:31 ` Steve Wise
2018-01-23 16:44 ` Jason Gunthorpe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='013a01d3946f$034683f0$09d38bd0$@opengridcomputing.com' \
--to=swise-7bpotxp6k4+p2yhjcf5u+vpxobypeauw@public.gmane.org \
--cc=bmt-OA+xvbQnYDHMbYB6QlFGEg@public.gmane.org \
--cc=jgg-uk2M96/98Pc@public.gmane.org \
--cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox