Re: 回复：回复：[PATCH v1 1/1] net/nbl: add VLAN offload set interface

[Stephen Hemminger <stephen@networkplumber.org>]

On Wed, 26 Nov 2025 09:52:19 +0800
"Dimon" <dimon.zhao@nebula-matrix.com> wrote:

> Hi Stephen,
> Thank you for your feedback. 
> We understand your technical concern regarding the VLAN offload implementation.
> Our implementation choice is driven by practical customer requirements.
> In real-world deployment scenarios, there is a strong expectation that basic VLAN offload capabilities are available and functional by default.
> Numerous customer applications, automation scripts, and network configurations rely on these standard VLAN operations "just working,"
> irrespective of whether the underlying mechanism is hardware-accelerated or software-based.
> Our current approach ensures that:
> Compatibility is maintained: Existing deployment tools and scripts function without any required modifications.
> Customer expectations are met: The fundamental VLAN functionality is present and operational.
> The alternative—returning -ENOTSUP—would indeed break a significant number of existing customer deployments that
> operate under the reasonable assumption that basic VLAN features are available.
> Thank you.
> ------------------------------------------------------------------

Never mind, I got confused.

The NBL device does report VLAN_STRIP in rx_offload_capa but since
it is doing it purely in software didn't notice that.
The other drivers doing VLAN all in software is virtio and dpaa2.

Your right the mask doesn't matter since the driver is directly looking
at rxmode.offloads to determine what to do.

Since you are running on ARM could see wrong value because the rxmode.offloads
is being updated in one thread and receive logic is running in another thread.
Looks like atomic operations might be necessary here (and virtio and dpaa2)
to be safe.

I will go ahead and recheck this and merge to next-net.