> > Just curious -- what's up with this change here? Is this connected to
> > IBoE support, or is this an independent fix?
>
> It is required for proper distribution of IBoE multicast packets while
> still not hurting the mlx4_en driver's operation.
OK, I split this into a separate patch for clarity.
> > Finally this patch would have been easier to review without extraneous
> > whitespace noise like
>
> Sorry about that. I pass them through checkpatch but this must have
> been hiden within the "line over ..." messages.
It's not a checkpatch issue. It's just that you made random formatting
changes to parts of the code that weren't otherwise touched.
> Roland, would you like me to send patches 8-12 again with this fixed?
I think I can still handle it.
However I notice one other thing that looks like a bug.
You add a function that starts:
int mlx4_ib_resolve_grh(struct mlx4_ib_dev *dev, const struct ib_ah_attr
*ah_attr,
u8 *mac, int *is_mcast, u8 port)
{
struct mlx4_ib_iboe *iboe = &dev->iboe;
struct in6_addr in6;
*is_mcast = 0;
spin_lock(&iboe->lock);
which is called from create_iboe_ah() which is called from
mlx4_ib_create_ah(), which can be called from both interrupt and process
context. So as far as I can tell, this spin_lock() needs to actually do
spin_lock_irqsave()?
- R.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
