[Bug 278130] [netgraph][patch] ng_bridge hooks should auto assign number for [up]link

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=278130

            Bug ID: 278130
           Summary: [netgraph][patch] ng_bridge hooks should auto assign
                    number for [up]link
           Product: Base System
           Version: 14.0-STABLE
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: dave@freedave.net

Created attachment 249661
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=249661&action=edit
patches and example ngctl for testing

The removal of NG_BRIDGE_MAX_LINKS in review D21803 has made it possible to
have way more than 32 connections to an ng_bridge. But there isn't any (easy)
way for userland to track available link names and requires listing all
existing [up]links or to just guess a number until one succeeds.

There appears to never be a need to know the link number of the hook on the
ng_bridge. When an ng_bridge shuts down it disconnects all hooks. If you know
the path of your ng_eiface, ng_socket, ng_ether, etc. you have a way to
`rmhook` without the link path. That is you can remove via either:
        rmhook <ng_bridge path> [up]linkX
or with
        rmhook <ng_eiface path> ether
Everything else that connects to ng_bridge has a similar option.

This change, however, is about removing the need to specify an [up]link number
when creating a connection to the ng_bridge. Using ng_eiface again it means
you can use:
        connect <ng_eiface path> <ng_bridge path> ether link
The ng_bridge will auto assign the lowest available [up]link number that is
valid.

The number space for [up]link is as large as an int, limited by the fact that
all netgraph nodes use an int to track the number of connected hooks they have,
nd_numhooks in struct ng_node. This turns out to be a convenient fact when
introducing unr(9) as I can just initialize to INT_MAX. But it also means you
could just take advantage of that and create a numbering scheme in user space.
For example:
        0,1 always reserved for ng_ether (which requires 2 hooks)
        16 - N reserved for bhyve
        N - INT_MAX reserved for jails
The only issue is that 3rd party scripts would have to agree (e.g. ezjail,
vm-bhyve, etc.) Each script would have to scan and when it finds an available
[up]link number hope its still there when it attempts the `connect`.

"uplink" was introduced with review D23963. I have preserved the requirement
you still can not have "uplink0". That will be automatically handled if you
connect and request "uplink", it will give you "uplink1" or higher depending on
availability but never "uplink0".

Because [up]link number is not required it also becomes possible to inspect
a netgraph node type and based on that determine the `peerhook` argument to
connect to an ng_bridge. I added a change to bhyve to do exactly that.

This allows for a simplification when using netgraph with bhyve, which became
possible with review D24620.
  Instead of:
    -t netgraph,socket=vm0,path=vmbridge:,hook=vm0link,peerhook=link0
  You can shorten to just:
    -t netgraph,path=vmbridge:

  Instead of:
    -t netgraph,socket=vm1,path=igb0:,hook=vm1link,peerhook=lower
  You can shorten to just:
    -t netgraph,path=igb0:

I'm just removing the need for `peerhook`. No need to specify `socket` or
`hook`
as the code exists today. Without this you could start just passing "link" for
peerhook when using an ng_bridge. It makes the bhyve change optional, and I'm
ok if its removed, I mostly care about not having to deal with numbering links
for my jails that use ng_eiface.

This change is not 100% backward compatible though. The unr(9) is shared by
`link` and `uplink`. The current code will allow `link1` and `uplink1` and this
change will not. The total number of [up]links is unchanged. But bear in mind
uplink is for a physical interface connected to an ng_bridge, and the
expectation is that you have only one of these, so it would be wasteful to have
a separate unr(9) for just "uplink". But other than that it does still allow
users to specify [up]link number.

The tarball contains patches for CURRENT and stable/14. stable/13 still uses
the
the array of 32 hooks with NG_BRIDGE_MAX_LINKS. It also contains some simple
tests to try with ngctl(8).

-- 
You are receiving this mail because:
You are the assignee for the bug.