Comment # 8
on bug 13213
from Parav Pandit
(In reply to Chuck Lever from comment #7)
> (In reply to Parav Pandit from comment #6)
> > (In reply to Chuck Lever from comment #5)
> > > The destination port for the client-to-server conversation does not match
> > > either the source port or the destination port for the server-to-client
> > > conversation. This defeats the RPC dissector's conversation-based XID
> > > matching mechanism.
> >
> > Its IP over IB.
>
> To be clear, NFS/RDMA is not the same as NFS on TCP on IPoIB.
>
> > so TCP/NFS dissector would look for src and dest port of TCP?
>
> Yes, NFS on TCP on IPoIB uses the port information established by the TCP
> layer.
>
> > While infiniband.c would do conversations based on src and dest qp.
>
> Correct. Note, however, that the dest QPN for the client-to-server
> conversation is not the same as the dest QPN for the server-to-client
> conversation.
>
> > Thats what I see in the logs and in trace as below.
> >
> > > update_sport frame=13 updating sport = 546, dport=525
> > > get_conversation_for_call frame=13 sport=55562 dport=111 conv=0x7f205dab1830
>
> Neither of the dport values is 20049, which is the standards-designated TCP
> port used for NFS/RDMA. So I would conclude from your log that these are not
> TCP ports.
>
> > Do packet-rpc.c find conversation based on IB srcport, destport or TCP ports?
>
> The current logic in packet-rpc.c treats PT_TCP and PT_IBQP the same, and
> expects that the pinfo will be set up so that:
>
> In the client-to-server direction: < addr A, port A, addr B, port B >
>
> In the server-to-client direction: < addr B, port B, addr A, port A >
>
> But for PT_IBQP, we have:
>
> In the client-to-server direction: < addr A, -1, addr B, dest QPN B >
>
> In the server-to-client direction: < addr B, -1, addr A, dest QPN A >
>
> packet-rpc.c's XID-matching mechanism doesn't work with those tuples. Just
> setting up the src port in the pinfo doesn't help because "dest QPN A" !=
> "dest QPN B" .
>
> To make PT_IBQP work like PT_TCP, maybe you'd need:
>
> In the client-to-server direction: < addr A, dest QPN A, addr B, dest QPN
> B >
>
> In the server-to-client direction: < addr B, dest QPN B, addr A, dest QPN
> A >
find_conversation() in conversation.c first performs exact lookup on tuple
<addr A, port_a(dst_qp), addr B, port B (src_qp), if it doesn't find it, than
it tries in reverse direction with tuple <addr B, port_B, addr A, port A>.
I was hoping that it finds it for packet-rpc.c.
I was able to confirm that it finds when I tested with nvme dissector.
You are receiving this mail because:
- You are watching all bug changes.