On 12/24/18 8:51 AM, Vasily Averin wrote: > On 12/24/18 2:56 AM, Trond Myklebust wrote: >> 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. > > We need to know which kind of transport is used in specified net namespace, > for example init_ns can use RDMA transport and netns "second" can use > TCP transport at the same time. > If you do not like an idea to use function pointer as a mark -- ok > I can save only some boolean flag on sunrpc_net, check it in svc_process_common() > and if it is set -- call svc_tcp_prep_reply_hdr() directly. moreover, I can do not change sunrpc_net at all, I can check in bc_svc_common() which transport uses incoming svc_req and provide such flag as new parameter to svc_process_common(). >> 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. >>
