In D42972#980141, @jhibbits wrote:

In D42972#980139, @glebius wrote:

Got it. Looks like there is also an assumption here that the first address is always the link level address. Maybe we just need to provide KPI if_getlladdr? May I ask to wait for Alexander melifaro@ to reappear before we proceed forward with that?

P.S. I'm also waiting for him on my netlink reviews.

Looking, we do have if_getlladdr(). It looks like the correct fix in 7d482240 should have been to just wrap the existing call in the epoch. @bz?

Looks good to me.

This is a behavior change. I think it deserves a Relnotes: Yes commit meta message.

In D54177#1238745, @markj wrote:

Good find.

In D53871#1239274, @glebius wrote:

In D53871#1239268, @zlei wrote:

I uploaded the patch to https://reviews.freebsd.org/F139754092 . I might miss some drivers but that should be almost completed. While working on this, I'm not fully convinced this is a good approach. I'd argue the bpf part is too tightly coupled with the net epoch.

Thanks a lot! Do you plan to commit? Maybe the watchdogged drivers can be generalized in some way...

In D54241#1239759, @glebius wrote:

In D54241#1239402, @zlei wrote:

I'm not familiar with netgraph. While I'm finding possible missing of net epoch context,

Okay, here is a short description. When data travels through netgraph(4) the context SHALL be in the net epoch. Thus, any rcvdata method is entered with the epoch.

It appears only ng_socket.c has done right. netflow.c, netflow_v9.c and ng_ppp.c lack proper net epoch context around NG_FWD_ITEM_HOOK(), then this change can lead regression and NET_EPOCH_ASSERT() will complain.

The ng_socket.c is an edge type of a node. It means that it has one side facing into netgraph and one side facing into somewhere else (write(2) syscall in case of ng_socket(4). The edge nodes are responsible for entering epoch when they inject data into netgraph. The netflow and ppp nodes are not edge nodes.

I'm not familiar with netgraph. While I'm finding possible missing of net epoch context,

I uploaded the patch to https://reviews.freebsd.org/F139754092 . I might miss some drivers but that should be almost completed. While working on this, I'm not fully convinced this is a good approach. I'd argue the bpf part is too tightly coupled with the net epoch.

@ziaee Does this look good to you ?

Replaced loop copying with memcpy() for better readability.

In D53871#1238154, @glebius wrote:

@zlei thanks for all these findings! It seems that at least few of them were violating epoch even before the suggested bpf change. Are you going to commit the fixes? I can help. To me some of these fixes do not look related to bpf at all.

The NET_EPOCH_ENTER() in sys/dev/iicbus/if_ic.c should be adjusted,

In D54107#1236540, @markj wrote:

Thank you for working on this, but for this driver I think it would be better to just have EXPORT_SYMS=yes rather than enumerating and maintaining the list of symbols. Otherwise this will be a headache for the upstream maintainer.

The lint check complains,

% mandoc -Tlint share/man/man9/locking.9  
mandoc: share/man/man9/locking.9:375:23: STYLE: no blank before trailing delimiter: Em        You want:
mandoc: share/man/man9/locking.9:376:16: STYLE: no blank before trailing delimiter: Em You have:
mandoc: share/man/man9/locking.9:411:15: STYLE: no blank before trailing delimiter: Em Context:

Addressed @ziaee 's comment.

Looks good to me.

I like this approach. This change will also relief the cache usage and have nice effect on performance.

In D54037#1234622, @imp wrote:

Why can't we make virtio_p9fs.ko depend on p9fs.ko?

Looks good to me.

I think this is the right approach.

I have no objections to do this. Well new code should prefer the standard types, but the existing code can be left as is.

Looks good to me.

Looks good to me.

So typically a queue is bound to one core, then we have better cache localization for the same flow ? That sounds a good idea.

Looks good to me.

Looks good to me.

I spent some time to learn the FreeBSD's RSS design. I do not have hardware to test, but the change looks good to me.

In D44204#1216519, @ae wrote:

It seems to have affected MLDv6: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290407

This is for other architectures, i386, arm, powerpc and riscv.

In D53101#1214510, @zlei wrote:

I'm not getting this change. The kernel build option RSS is not enabled by default. Is this change want to enable a variant RSS when RSS is not enabled in the kernel ?

I'm not getting this change. The kernel build option RSS is not enabled by default. Is this change want to enable a variant RSS when RSS is not enabled in the kernel ?