In D23097#511996, @hselasky wrote:

I mean that vnet0 behaves like any other vnet regarding shutdown and state fields.

In D23097#511548, @hselasky wrote:

Ping - is this patch still relevant?

One small nit on a comment.

It's extremely hard in Phabricator to follow the changes between the last round and this so I am not sure I found all the changes fixed and comments done.

Can you please update the diff? I doen't apply cleanly to head (anymore):

Hi Glebius, I have a patch which tried to remove recursions within netinet6. I was down to one in December and since new ones have shown up. I am not sure if I'll be able to look at this one before next week but I'll try to upload my current work in progress in case that'll help you. I have EPOCH calls around all ip6_output() calls which this one equally adds, so most of my changes should be "downstream" from yours.

In D23145#507260, @manu wrote:

The bindings (https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L16) seems to indicate
that mac-address should be used if it exists and is prefered to local-mac-address.
Maybe change dwc_get_hwaddr_fdt to handle that and make it a generic helper ?

I'll be happy to have a look (probably next week and once the redirect stuff is in)

I've not looked at the test cases (yet) in particular detail.
There's 2 or 3 functional questions, most is just comments and whitespace.

The AF can be set in in6_inithead() already but I understand if you want to do all in the callers together; sounds like a good compromise for an MFC :-) Thanks!

Thank you so much for splitting this out. It really helps a lot! спасибо большой!

For @hselasky: this does not yet fix the vnet0 issue. That'll be sorted out after this.

I've a patch with this + the LLVM changes running on arm64 for a bit:

I'll go ahead and commit it anyway; I think the is no need to refine the review again.

Seems this needs someone to commit it; I'll try to do this afternoon (timezone unspecified ;-)).

In D22988#504235, @melifaro wrote:

I have a very annoying question: how much extra work would it be to split this up into: (a) adding rib_fibnum, rib_family and rib_vnet fields and changing the KPI for them by adding them to the current calls and then (b) adding the new functionality (and changing the support function logic beyond just passing the extra fields around)?
It would make the change history much more clear and also make it easier to review things.

Looks good to me.

In D22865#500609, @ae wrote:

I meant this thread: https://lists.freebsd.org/pipermail/freebsd-net/2019-October/054632.html

In D22865#500605, @ae wrote:

We removed this code two years ago, since it adds big penalty for routers where are tens of thousands IPv6 routes.
However, someone in the mail list recently complained that we have not a method for route expiring, probably we can rework this code to implement such feature.

The v6 change looks ok to me for as much as I still understand the code.

I was wondering if we can have a man page along with this as my first question was "what kind of driver is this?" Sadly the description of this review doesn't say much.

I'l split this up into a couple of chunks so we can more easily do the base infrastructure for the llatbl changes for IPv6 and the IPv4.
The rtr and prefix parts are unrelated to that.

In case I don't hear from you I'll go ahead and commit this the next days.

Thanks a lot for the feedback. let me know what you think about the suggestion to move the basic functionality into llatbl?

Address variable naming.
Address conditional checks.

Ignoring the one maximum value, is anyone interest in actually reviewing this?

inet_pton() stroes network byte order, so lose the original (now extra)
htonl() and unbreak IPv4 support.

In D22487#491857, @darkfiberiru_gmail.com wrote:

Trying to understand your bootp comment in summary. Are you pointing at no support yet for https://tools.ietf.org/html/rfc5970 or that there just isn't a ipv6 option for defining boot info like bootp had?