Comment # 11
on bug 13213
from Parav Pandit
Hi Chuck,
I didn't get chance yesterday to debug this further. I did now.
(In reply to Chuck Lever from comment #10)
> (In reply to Parav Pandit from comment #9)
> > (In reply to Chuck Lever from comment #7)
> > > 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 >
> > >
> >
> > My patch has src_qp instead of -1 for srcport.
>
> I assume "My patch" == the packet-infiniband.c hunk from change 19107
>
Yes.
> I don't know what "src_qp" is. Only destination QPNs appear on the wire.
> Perhaps we should stick with calling these destination QPNs. Where are you
> getting these QPNs?
>
Yes. only one Destination QPN appears on the wire out of 2 (one in each
direction). So below two look up cannot map to same conversation, unless we
ignore both the ports using NO_PORT_A, NO_PORT_B, which will just make it
network loop and not L4 lookup, which won't work.
<addr A, addr B, -1, dest QPN B>
<addr B, addr A, -1, dest QPN A>
> How does 19107's packet-infiniband.c hunk behave with packet-rpc.c and, say,
> the sample wire capture excerpt attached to this bug?
I tested this further and found the bug in packet-infiniband.c where
bididirectional entry has typo.
I fixed it and with that now packet-rpc.c doesn't need to deviate lookup for
TCP and Infiniband transport.
I tested attached patch excerpt.pcap of this bug and I can see frame 54's
response is in 56. 58th frames response in 60 without changes. Both match up to
same conversation without applying patch of Comment 4.
Instead of proc0 entry, I can see now "call in 58" and "reply in 56" for those
frames.
I am going to resubmit the patch with hunk of 19107 for infiniband.c along with
additional fix with this bug id. You can possibly drop the hunk to diverge code
for tcp and infiniband of packet-rpc.c
You are receiving this mail because:
- You are watching all bug changes.