On Sat, 2018-12-22 at 20:46 +0300, Vasily Averin wrote: > On 12/21/18 4:00 AM, bfields@xxxxxxxxxxxx wrote: > > On Tue, Dec 18, 2018 at 02:55:15PM +0000, Trond Myklebust wrote: > > > No. We don't care about xpt_flags for the back channel because > > > there is > > > no "server transport". The actual transport is stored in the > > > 'struct > > > rpc_rqst', and is the struct rpc_xprt corresponding to the client > > > socket or RDMA channel. > > > > > > IOW: All we really need in svc_process_common() is to be able to > > > run > > > rqstp->rq_xprt->xpt_ops->xpo_prep_reply_hdr(), and that can be > > > passed > > > either as a pointer to the struct svc_xprt_ops itself. > > > > For what it's worth, I'd rather get rid of that op--it's an awfully > > roundabout way just to do "svc_putnl(resv, 0);" in the tcp case. > > Do you mean that svc_create_xprt(serv, "tcp-bc", ...) was used ONLY > to call > svc_tcp_prep_reply_hdr() in svc_process_common() ? > And according call for rdma-bc does nothing useful at all? > > I've just tried to remove svc_create_xprt() from xs_tcp_bc_up() and > just > provide pointer to svc_tcp_prep_reply_hdr() in svc_process_common() > via per-netns sunrpc_net -- and seems it was enough, my testcase > worked correctly. I don't see how that function is related to net namespaces. As far as I can tell, it only signals whether or not the type of transport uses the TCP record marking scheme. IOW: it depends on whether the client is using a stream based protocol like TCP, or a datagram-like protocol like UDP, or RDMA. Whether that use is occurring in a private net namespace or in the init process namespace would be irrelevant. > Am I missed something probably? > Should we really remove svc_create_xprt( "tcp/rdma-bc"...) related > stuff? ? Agreed. The 'bc_up' callback in struct rpc_xprt_ops serves no discernible purpose, and can be removed. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
