All of lore.kernel.org
 help / color / mirror / Atom feed
* pyverbs testing on rxe
@ 2020-09-04 18:03 Bob Pearson
  2020-09-04 18:20 ` Jason Gunthorpe
  0 siblings, 1 reply; 2+ messages in thread
From: Bob Pearson @ 2020-09-04 18:03 UTC (permalink / raw)
  To: Jason Gunthorpe, linux-rdma

Jason,

I am down to two errors and about 30 skips in run_test.py. device_ex, cq_ex and qp_ex verbs are working.

The two errors are from the same source and occur for async multicast rdmacm. The immediate cause of the problem is the test harness is setting up an IPv4 multicast address and then two end points start sending traffic to that address. These packets are delivered to the driver and received by rxe_rcv which tries to resolve a gid table entry for them and fails.

The unicast IPv4 address is 192.168.0.21 which does have a gid table entry. The multicast address is 230.168.0.21 which does not. Presumably the driver wants the gid table entry so it can use it to provide a source address for return traffic but that would just be the unicast address I think. The network stack knows which interface the traffic was received on but rdma/core is trying to solve the problem with just the IP address and doesn't seem to recognize it as a multicast address or have any clever idea what to do besides searching the gid table.

This seems to be a rdma/core issue more than a rxe issue. But it must have come up in the past somewhere.

BTW I got around the other addressing problem I was having by just adding the eui48 IPV5 address by hand with ip addr add.

Bob

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: pyverbs testing on rxe
  2020-09-04 18:03 pyverbs testing on rxe Bob Pearson
@ 2020-09-04 18:20 ` Jason Gunthorpe
  0 siblings, 0 replies; 2+ messages in thread
From: Jason Gunthorpe @ 2020-09-04 18:20 UTC (permalink / raw)
  To: Bob Pearson; +Cc: linux-rdma

On Fri, Sep 04, 2020 at 01:03:40PM -0500, Bob Pearson wrote:
> The unicast IPv4 address is 192.168.0.21 which does have a gid table
> entry. The multicast address is 230.168.0.21 which does
> not. Presumably the driver wants the gid table entry so it can use
> it to provide a source address for return traffic but that would
> just be the unicast address I think.

What is the call stack like around this?

It should be using a route lookup to get the src IP to map to a gid
address

> BTW I got around the other addressing problem I was having by just
> adding the eui48 IPV5 address by hand with ip addr add.

Hum, seems like this is still a core code bug that should be fixed
though

Jason

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2020-09-04 18:20 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-04 18:03 pyverbs testing on rxe Bob Pearson
2020-09-04 18:20 ` Jason Gunthorpe

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.