Jason Gunthorpe wrote:
OFED works on kernels that have compiled-in inline'd multicast map functions
that do not include the pkey copy, while mainline's multicast map functions do.
So to work around this there is a bit of code in OFED to overwrite the pkey in
the multicast hw address. This
Jason Gunthorpe wrote:
Be aware that mainline and OFED are different in this regard, OFED overrides
the pkey unconditionally for multicast addresses, while mainline doesn't
Can you clarify this, please?
ipoib bonding had much the same problem with invalid maddrs, and a
patch was put in
Jason wrote:
What happens if the SM reprograms the pkey table later?
I'm not sure this is the right approach.. See the recent dicussion
about using pkey indexes at all.
Each ipoib interface is assigned a pkey, by number, not index. If the
SM has not supplied that pkey to the port then
On Fri, Jun 18, 2010 at 12:32:52PM -0500, Todd Rimmer wrote:
For IB, the centralized tool is the SM and a VLAN is an IB
Partition. The present capability of using the 1st PKey table entry
is a nice simple and powerful way to mimic the ease of use of
Ethernet VLANs. Only when a user wants
Jason wrote:
You cannot easily change the broadcast GID after starting. It gets
into places, and this patch does not address that. I suspect that
un-doing all the places the GID gets into is fairly hard..
We have successfully tested this patch by bouncing the SM with a new partition
table
On Fri, Jun 18, 2010 at 12:56:56PM -0500, Todd Rimmer wrote:
Jason wrote:
You cannot easily change the broadcast GID after starting. It gets
into places, and this patch does not address that. I suspect that
un-doing all the places the GID gets into is fairly hard..
We have successfully
Jason,
Fixing the maddr table, and dealing with race issues with ongoing
joins my not be straightforward, but, IMHO, necessary for this patch
to be acceptable.
So you are pointing out an existing bug, which is no worse with this patch than
without it. Namely that pkey changes with IPv6
On Fri, Jun 18, 2010 at 01:38:13PM -0500, Todd Rimmer wrote:
Jason,
Fixing the maddr table, and dealing with race issues with ongoing
joins my not be straightforward, but, IMHO, necessary for this patch
to be acceptable.
So you are pointing out an existing bug, which is no worse with
