Hi Bernard, Thanks for the review comments. Replied in line. On Tuesday, May 05/05/20, 2020 at 11:19:46 +0000, Bernard Metzler wrote: > > -----"Krishnamraju Eraparaju" <krishna2@xxxxxxxxxxx> wrote: ----- > > >To: "Bernard Metzler" <BMT@xxxxxxxxxxxxxx> > >From: "Krishnamraju Eraparaju" <krishna2@xxxxxxxxxxx> > >Date: 04/28/2020 10:01PM > >Cc: faisal.latif@xxxxxxxxx, shiraz.saleem@xxxxxxxxx, > >mkalderon@xxxxxxxxxxx, aelior@xxxxxxxxxxx, dledford@xxxxxxxxxx, > >jgg@xxxxxxxx, linux-rdma@xxxxxxxxxxxxxxx, bharat@xxxxxxxxxxx, > >nirranjan@xxxxxxxxxxx > >Subject: [EXTERNAL] Re: [RFC PATCH] RDMA/siw: Experimental e2e > >negotiation of GSO usage. > > > >On Wednesday, April 04/15/20, 2020 at 11:59:21 +0000, Bernard Metzler > >wrote: > >Hi Bernard, > > > >The attached patches enables the GSO negotiation code in SIW with > >few modifications, and also allows hardware iwarp drivers to > >advertise > >their max length(in 16/32/64KB granularity) that they can accept. > >The logic is almost similar to how TCP SYN MSS announcements works > >while > >3-way handshake. > > > >Please see if this approach works better for softiwarp <=> hardiwarp > >case. > > > >Thanks, > >Krishna. > > > Hi Krishna, > > Thanks for providing this. I have a few comments: > > It would be good if we can look at patches inlined in the > email body, as usual. Sure, will do that henceforth. > > Before further discussing a complex solution as suggested > here, I would like to hear comments from other iWarp HW > vendors on their capabilities regarding GSO frame acceptance > and potential preferences. > > The extension proposed here goes beyond what I initially sent > as a proposed patch. From an siw point of view, it is straight > forward to select using GSO or not, depending on the iWarp peer > ability to process large frames. What is proposed here is a > end-to-end negotiation of the actual frame size. > > A comment in the patch you sent suggests adding a module > parameter. Module parameters are deprecated, and I removed any > of those from siw when it went upstream. I don't think we can > rely on that mechanism. > > siw has a compile time parameter (yes, that was a module > parameter) which can set the maximum tx frame size (in multiples > of MTU size). Any static setup of siw <-> Chelsio could make > use of that as a work around. > > I wonder if it would be a better idea to look into an extension > of the rdma netlink protocol, which would allow setting driver > specific parameters per port, or even per QP. > I assume there are more potential use cases for driver private > extensions of the rdma netlink interface? I think, the only problem with "configuring FPDU length via rdma netlink" is the enduser might not feel comfortable in finding what adapter is installed at the remote endpoint and what length it supports. Any thoughts on simplify this? Thanks, Krishna. > > Thanks a lot! > Bernard. >
