On 10/3/18 8:59 AM, Stephen Hemminger wrote:

On Mon,  1 Oct 2018 17:28:26 -0700
David Ahern [off-list ref] wrote:

quoted

How to resolve the problem of not breaking old userspace yet be able to
move forward with new features such as kernel side filtering which are
crucial for efficient operation at high scale?

What about forward compatibility? How would this work when running new iproute2
command on older kernels?

I expect the new command would set the "I am smart flag" and the older
kernel would ignore it. The if the header for the message type had
changed, the dump would be broken.

The kernel today happily ignores garbage in the request it does not
understand. If the new iproute2 sends a dump request with attributes or
fields in the header set the kernel ignores it.

With the setsockopt option for setting the flag, userspace knows the
kernel does not support attribute checking and kernel side filtering.

As far as changing the header (new iproute2 on old kernel), there are 3
dumps that look at the header beyond the family:
1. link dumps - but it has the expected ifinfomsg header

2. neighbor dumps (expects the right ndmsg header)

3. fdb dumps - wrongly expect ifinfomsg header but there is patch to
detect when the ndmsg header is sent (ip neigh vs bridge fdb)

The 4th dump that looks at the header is addresses. Those patches were
added in this development cycle. Those dumps need to be wrapped in the
'userspace has a clue' setting or reverted until this is figured out.