In D25873#573627, @np wrote:

In D25873#573456, @lutz_donnerhacke.de wrote:

In D25873#573447, @hselasky wrote:

Aren't we soon running out of flag bits in certain integer values?

Given that the inner flags mirror the outer ones, why not use a different variable inner_flags with the same set of flags?

That would work, but it would increase the size of struct mbuf.

In D25873#573447, @hselasky wrote:

Aren't we soon running out of flag bits in certain integer values?

May you please consider splitting the patch into functional groups?

• VXLAN HW capabilities
• Spelling errors
• Logic cleanup "xxx == 0" vs "!xxx"
• style cleanup

Thanks.

What's the reason behind this proposal?

In D25789#572558, @2khramtsov_gmail.com wrote:

Improve test and do the same with kernel module as pf tests do.

Thanks.

Ping

Revert errornous comparsion

Rebase to current

Good work, thank you.
If possible convert your test into a real test file for regressions.

In D25788#571362, @markj wrote:

In fact, for ng_iface it is possible for the node and ifnet VNETs to become out of sync: if I create two ng_iface interfaces and pass one into a jail, the node's VNET is not updated but the ifnet's VNET is updated.

In D25788#571336, @markj wrote:

In D25788#571211, @lutz_donnerhacke.de wrote:

So - in order to handle this problem - the ng_iface node need to validate the incoming data messages and

• supply the missing VNET information
• overwrite(?) a wrong VNET information

Why is it not sufficient for ng_iface to simply set the current vnet in ng_iface_rcvdata()?

Because the ABI break spans the kernel / userland barrier, the update procedure for the FreeBSD base system is harmed.
An old ipfw will send the old TOK_xxx values, which will be misinterpreted by a new kernel.
Please find a way to keep the old ipfw binary working during the upgrade.

Thank you for your contribution, especially for using the documentation prefixes in your examples.
Because your test plan is so detailed, you may consider to write is as a regression test for constant revalidation.

ng_tty is the wrong place for deciding this question. Almost any netgraph node is able to send data over a hook, most of them are VNET agnostic. The correct vnet depends on the context of the ng_iface node.

In D25681#568368, @eugen_grosbein.net wrote:

ce(4) for PCI G.703/E1 card,
cp(4) for PCI V.35/RS-232/RS-530/RS-449/X.21/G.703/E1/E3/T3/STS-1 cards,
and cx(4)/ctau(4) for some ISA cards but these do not exist in FreeBSD 13 anymore,
removed by emaste@ recently.

Both ce(4) and cp(4) are i386-only drivers at present.

In D25607#566660, @rgrimes wrote:

I also have concerns over any performance claims, though I see the old code is probably at least sub optimal in that it often checks for UDP, then for TCP when the volume of traffic should almost always be mostly TCP.

This will bring in a better coding style and improved readability.
But for the speed improvement, I'd like to see some evidence.

May somebody with commit rights push this into the kernel and may have a kind look on my other open reviews ...

In D23888#565421, @neel_neelc.org wrote:

Unbreak build on recent CURRENT by using memcpy.

From the netgraph part, there is no objection.

I'd suggest to stop processing at this place.

Good catch.

In RFC 6437 there is no rule, that flow labels are immutable for a given TCP session. It only notes in section 6.1, that changing the flow label within a TCP stream might be suspicious.
IPv6 flow labels are designed as QoS/routing indicators (like the DCSP field), which (in theory) might vary during the life time of the TCP session.

May you be so kind as adding some lines into the man page, too?
Otherwise those are some more of the obscure sysctls, which are even not documented in the source code.

If I understand correctly

ifconfig -a -g lagg -G lagg*1

will match all lagg interfaces besides those ending in 1.

In D25029#551707, @eugen_grosbein.net wrote:

In D25029#551705, @ae wrote:

You can just use another option name to specify excludes.

Good point, -G would do it for negation.

In D24021#546333, @neel_neelc.org wrote:

In this patch, "me4" is IPv4-only and "me" is dual-stack. It uses kernel opcodes, however.

Can you point to existing implementations of this idea?
Several middle-ware boxes are prone to assumptions like one-port-one-connection.
I doubt, that this will work with i.e. restricted cone NAT (https://en.wikipedia.org/wiki/Network_address_translation)

I'm still fine with the netgraph part.

In D24427#544221, @ae wrote:

JFYI, this code will be removed when refactoring to the epoch(9) will be finished.

"del" is a bad name for the running variable. I'd feel "prev" more appropriate.

I assume, it is common practice to not explicitly assert(be != NULL) in each of the functions.

I tried the code generation with:

int testFP(int i) {
   return i*0.75;
}

In D24620#543377, @aleksandr.fedorov_itglobal.com wrote:

• Change the "path" option to "relpath" to match the ngctl connect command.

Your test defines a node named "vmbridge".

host# ngctl name ngeth0:ether vmbridge

and then referes to a node "vmbr"

host# sh vmrun.sh -c 4 -m 1024M -t netgraph:socket=vm0:path=vmbr:hook=vm0link:peerhook=link0 -d freebsd-0.img freebsd-0

In D24620#542160, @aleksandr.fedorov_itglobal.com wrote:

In D24620#541979, @lutz_donnerhacke.de wrote:

If I understand correctly, you are adding code in the VM-setup (copied from ngctl) to create a ng_socket and connect it to a specified node (ng_bridge). Then you are using the data channel of the ng_socket to transmit Ethernet frames.

Yes. This is how bhyve network backends works. The guest OS sends / receives packets through the guest driver, bhyve processes them in user space and redirects them to the appropriate device using read / write / mmap system calls. Bhyve currently supports packet processing through /dev/tapX and /dev/netmap.

This review add support packet processing through ng_socket(4). I only know two useful ways to send/receive packets to/from the Netgraph network from the user space: ng_socket and ng_device (open /dev/ngdN and read/write).

If I understand correctly, you are adding code in the VM-setup (copied from ngctl) to create a ng_socket and connect it to a specified node (ng_bridge). Then you are using the data channel of the ng_socket to transmit Ethernet frames.

Fix issues in the code, i.e. bitfields are unsigned, spacing style, braces style.

Fix various man page issues.

Is there really a typical use case for this call?

What about src-ipv4? (for the sake of symmetry)
Somebody may think about "*ip" to accept both address families.

Patch does work with 12-STABLE, too. (removing the NEEDGIANT flag)

Fixed spacing for "if (" statements.
Running the whole source through indent(1) would make a much larger patch.

That would be my approach https://reviews.freebsd.org/differential/diff/69565/
I'd further eliminate the temporary storage "struct sockaddr_storage result", and copy directly from the gai result into the action (with memcpy).

I tried to use the already existing socket infrastructure to change the socket buffer values ...

In D24021#528343, @driesm.michiels_gmail.com wrote:

Does this mean that for a current dual stack IPFW rule like:

allow tcp from any to me 443

It will only match for IPv4 packets, as "me" is only working with IPv4 addresses under the hood with the current behavior?
This is not the current behavior I'm observing since my web server answers IPv6 requests perfectly fine with my above rule.

Good catch.

In D23971#528126, @rgrimes wrote:

I have no idea why someone thinks a network device should have a minimum MTU of 1280, that is simply the IPv6 value, ethernet is very happy to transfer 64 byte packets. There should be some implementation detail of the in kernel vt driver that can at least go that small, and perhaps smaller as you do not have the collision detection minimum wire time that ethernet has(had).

In D24011#527998, @lutz_donnerhacke.de wrote:

How about detecting the port separator first? (i.e. repeatly call strpbrk)

How about detecting the port separator first? (i.e. repeatly call strpbrk)
Then you can easily distinguish between the cases

• starts with '[' -> numeric IPb6
• contains ':' -> numeric IPv6
• contains no letters -> numeric IPv4
• use gai()

Ping?

Ping?

Ping?

@melifaro Are your concerns resolved?

@hrs Are your concerns resolved?

@brueffer Are your concerns resolved?

Widen the range of priority classes.

I'm sorry, but I do not see anything functionally connected with the new fib number.
This patch only stores and retrieves the number but does not consider it in its natting process itself.
So the whole fib processing is done in the ipfw ruleset, it has nothing to do with libalias.
What do I miss?

In D23963#526951, @aleksandr.fedorov_itglobal.com wrote:

Is it really useful to have multiple uplinks?

Updated to revision 358668.

The man page needs an update, too.

In D23721#526022, @glebius wrote:

This can make sense in certain setups. However, since originally node provided writable copies to each of "many" hooks, we can't change that. This can be configured as a node option, if sysadmin is sure that nodes downstream of "many" hooks are fine with read only mbufs.