Use a macros to check if the vnet is shutting down in if.c.

In D23145#520891, @kevans wrote:

In D23145#520806, @bz wrote:

Any comments on this? I'd love to get the change out of my tree soon..
I am also interested in "this is what we were thinking of" comments.

I did wonder if the common fdt method should guarantee a MAC address and call ether_gen_addr() itself if it couldn't find an applicable fdt prop, maybe with an ENOENT to indicate that it was generated rather than found (0)- this would avoid drivers having to then call ether_gen_addr() themselves if it fails, which I kind of suspect might be the common case. I'm unsure, though.

Any comments on this? I'd love to get the change out of my tree soon..
I am also interested in "this is what we were thinking of" comments.

Anyone any further comments on this? I'd love to commit it the next days.

Update the change factoring out the fdt logic to resemble the USB one.
Is this what you were thinking of?

Address reviewer comments.

In general I like the idea. Still need to touch network drivers but changing a single macro seems way better to me. It's also easily grep-able.

I have a follow-up question to all this stuff which I do not understand yet:

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.