> > I don’t like the overloading of the term 'lid' to sometimes mean a > 16-bit value and other times a 32-bit value, with no way of > distinguishing which one we have. Maybe we need to call out a version > (lidv2 = 32-bits) or carry the size. I don't have a strong idea here. > But when looking at this patch, lid is re-defined to u32, then nearly > everywhere cast back to u16, which looks questionable. > The intention was to not cause too many changes to the underlying > drivers when the lid field was increased. Casting was a simpler > approach. The problem is this is how most of the stack has evolved, and the resulting architecture is a mess. This is fundamentally changing the definition of what a LID is. For example, why stop at 4 bytes? Why not let the LID store a MAC address? At some point we need to deal with the fact that we have devices that support completely different L2, L3, and/or L4 addresses. And even where the addresses are the same size, they aren't from the same domain. Does anyone know how the net stack handles this? Are we looking at an array of bytes + length? -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
