The capsicum support should look something like this:
Wed, Apr 28
Have you tested this code with CAPSICUM enabled?
Apr 7 2021
As I mentioned previously, the other thing to consider when using kvmclock in the current patch is the need for a system call for clock_gettime(), gettimeofday(), etc.
@me_freebsd_mathieu.digital, what a CPU model was used for testing?
Mar 30 2021
Mar 28 2021
Mar 27 2021
Mar 11 2021
I have no objections.
Mar 2 2021
Mar 1 2021
Feb 20 2021
I'm not an English expert, so you may be right.
Technically, I have no questions, I think this patch can be committed.
Feb 18 2021
Did you mean D28559?
Feb 15 2021
I have no competence in this area. Maybe you wanted to add @fsu to the reviewers? He was working on improving ext2/3/4 support.
Feb 5 2021
Jan 13 2021
Lutz, do you have any plans for the upcoming changes?
I also thought about getting rid of ng_bridge from NG_NODE_FORCE_WRITER. Since rcv_data is always called in the NET_EPOCH context, I think we can do it like @kp did it for if_bridge(4) (see D24250).
Dec 18 2020
I don't really like how ng_etner(4) is implemented as a whole. But I think this patch is correct and should be committed.
Dec 17 2020
Dec 6 2020
@grehan do you have any objections?
Dec 3 2020
Nov 29 2020
Eliminate issues identified by reviewers.
Nov 27 2020
@vmaffione, what do you think about this patch?
Nov 26 2020
Add a comment about locking.
Nov 19 2020
Nov 18 2020
Oct 14 2020
Oct 13 2020
I see various errors in the man page:
Oct 5 2020
Sep 29 2020
Do you have any performance measurements?
Is it have advantages over injecting packets through ng_socket(4) or ng_device(4)?
Sep 25 2020
Is this PR: 241133 ?
Sep 20 2020
After looking at your abandoned review (D26420) where you add parsing of IPv6 addresses. I wondered if we could use the generic inet_aton(3) functions available from kernel space?
Sep 14 2020
Aug 18 2020
Sorry to start a discussion here, but we have a similar problem with bhyve. When it is necessary to deliver packets from VM with partial checksum and TSO to the host stack (inbound path).
For example, we need to solve the next path:
VM (virtio-net, TSO, partial checksum) -> if_bridge/ng_bridge -> if_tuntap/ng_eiface -> host stack.
Aug 16 2020
I really like the changes related to option handling.
Jun 23 2020
May 16 2020
May 15 2020
May 8 2020
@vmaffione , do you have any objections?
- Use ',' as options separator.
- Move '#include <sys/sysctl.h>' to NETGRAPH section.
- Free optscopy early.
- While I'm here, fix a memory leak in e1000 frontend.
May 7 2020
- Fix the indicated issues.
May 6 2020
It looks good to me. Thank you.
May 5 2020
@vmaffione , I left '/' as a separator, because ';' used by the shell (tcsh, sh), so there is a need to enclosure the option string.
I think the best solution is still to pass the full line of options to the backend. Then we can use ',' as the delimiter.
I have not completely understood how backward compatibility can be broken? May you clarify?
- Reuse tap backend functions.
@vmaffione do you have any objections?
May 4 2020
- Revert: 'relpath' -> 'path' option.
- Correctly calculate the maximum available socket buffer size, as is done in the kernel.
Please keep it "path".
"relpath" is useless in this situation, because your node is not yet connected and can't use a relative path at all.
- Return -1 earlier if an error occurs.
- Change separator from ':' to '/' to allow different Netgraph address types (See man 4 netgraph 'Addressing').
- Fix resources leak through ctrl_sock.
- Change the "path" option to "relpath" to match the ngctl connect command.
May 3 2020
May 1 2020
I will try to fix all the places.
Apr 30 2020
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.
Apr 29 2020
Apr 25 2020
Apr 24 2020
Mar 31 2020
Are there any objections to not committing this?
Mar 29 2020
Mar 28 2020
- Allow entering MTU value in HEX.
Mar 19 2020
I tested this patch in our test lab with a lot of netgraph nodes. And I find it very useful.
I look at this issue from network virtualization point of view.
I have a plan (and patches) for adding native Netgraph support to the Bhyve network backend through ng_socket(4).
For this case, it is very interesting to be able to create ng_bridge(4) with the following options:
- One "uplink" hook with learning turned off, but all unknown MAC's go through it.
- The rest of the hooks have learning enabled, but unknown MAC's are not sent to them.