On Wed, 26 Nov 2025 09:52:19 +0800 "Dimon" <[email protected]> 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.
