[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20200907220408.32385-1-paul.davey@alliedtelesis.co.nz>
Date: Tue, 8 Sep 2020 10:04:05 +1200
From: Paul Davey <paul.davey@...iedtelesis.co.nz>
To: "David S. Miller" <davem@...emloft.net>
Cc: netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
Paul Davey <paul.davey@...iedtelesis.co.nz>
Subject: [PATCH net-next v2 0/3] Allow more than 255 IPv4 multicast interfaces
Currently it is not possible to use more than 255 multicast interfaces
for IPv4 due to the format of the igmpmsg header which only has 8 bits
available for the VIF ID. There is space available in the igmpmsg
header to store the full VIF ID in the form of an unused byte following
the VIF ID field. There is also enough space for the full VIF ID in
the Netlink cache notifications, however the value is currently taken
directly from the igmpmsg header and has thus already been truncated.
Adding the high byte of the VIF ID into the unused3 byte of igmpmsg
allows use of more than 255 IPv4 multicast interfaces. The full VIF ID
is also available in the Netlink notification by assembling it from
both bytes from the igmpmsg.
Additionally this reveals a deficiency in the Netlink cache report
notifications, they lack any means for differentiating cache reports
relating to different multicast routing tables. This is easily
resolved by adding the multicast route table ID to the cache reports.
changes in v2:
- Added high byte of VIF ID to igmpmsg struct replacing unused3
member.
- Assemble VIF ID in Netlink notification from both bytes in igmpmsg
header.
Paul Davey (3):
ipmr: Add route table ID to netlink cache reports
ipmr: Add high byte of VIF ID to igmpmsg
ipmr: Use full VIF ID in netlink cache reports
include/uapi/linux/mroute.h | 5 +++--
net/ipv4/ipmr.c | 14 ++++++++++----
2 files changed, 13 insertions(+), 6 deletions(-)
--
2.28.0
Powered by blists - more mailing lists