On 2/18/2020 7:42 PM, Jason Gunthorpe wrote:
On Mon, Feb 10, 2020 at 08:19:44AM -0500, Dennis Dalessandro wrote:
From: Gary Leshner <Gary.S.Leshner@xxxxxxxxx>
When in connected mode ipoib sent broadcast pings which exceeded the mtu
size for broadcast addresses.
Add an mtu attribute to the rdma_netdev structure which ipoib sets to its
mcast mtu size.
The RDMA netdev uses this value to determine if the skb length is too long
for the mtu specified and if it is, drops the packet and logs an error
about the errant packet.
I'm confused by this comment, connected mode is not able to use
rdma_netdev, for various technical reason, I thought?
Is this somehow running a rdma_netdev concurrently with connected
mode? How?
No, not concurrently. When ipoib is in connected mode, a broadcast
request, something like:
ping -s 2017 -i 0.001 -c 10 -M do -I ib0 -b 192.168.0.255
will be sent down from user space to ipoib. At an mcast_mtu of 2048, the
max payload size is 2016 (2048 - 28 - 4). If AIP is not being used then
the datagram send function (ipoib_send()) does a check and drops the packet.
However when AIP is enabled ipoib_send is of course not used and we land
in rn->send function. Which needs to do the same check.
Alternatively, the mcast_mtu check could be added to ipoib so that this
checking is performed before rn->send() is called. In that case, this
patch will not be needed and the new rdma_netdev (or clnt_priv) field
that shadows mcast_mtu would also not be needed.
Also for the datagram mode case, the ping command will correctly check
the payload size and drop the request in the user
space so that ipoib will not receive the broadcast request at all:
ping -s 2017 -i 0.001 -c 1 -M do -I ib0 -b 192.168.0.255
WARNING: pinging broadcast address
PING 192.168.0.255 (192.168.0.255) from 192.168.0.1 ib0: 2017(2045)
bytes of data.
ping: local error: Message too long, mtu=2044
-Denny
