From: Julian Anastasov <ja@xxxxxx> Date: Mon, 6 Feb 2017 23:14:10 +0200 > This patchset addresses the problem of neighbour > confirmation where received replies from one nexthop > can cause confirmation of different nexthop when using > the same dst. Thanks to YueHaibing <yuehaibing@xxxxxxxxxx> > for tracking the dst->pending_confirm problem. This looks good enough to apply to net-next, so I have done so. Thanks Julian! > - I failed to understand the CXGB* code, I see dst_confirm() > calls but I'm not sure dst_neigh_output() was called. For now > I just removed the dst->pending_confirm flag and left all > dst_confirm() calls there. Any better idea? As I said, it is trying to confirm neighbours based upon traffic occurring in the chips TCP offload stack. The 'cm' in "iwch_cm.c" means "connection manager". We can probably get to the neigh that will end up being used since there should be a flow key somewhere that we can use to determine the nexthop address for neigh lookup. > - Now may be old function neigh_output() should be restored > instead of dst_neigh_output? Please elaborate. Thanks. -- 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
