Hi Stephen,
Thank you for the review. I really appreciate your insights and the fix.
------------------------------------------------------------------
发件人：Stephen Hemminger <[email protected]>
发送时间：2025年11月27日(周四) 06:16
收件人：Dimon<[email protected]>
抄 送：dev<[email protected]>; Kyo Liu<[email protected]>;
Leon<[email protected]>; Sam<[email protected]>;
techboard<[email protected]>
主 题：Re: 回复：回复：[PATCH v1 1/1] net/nbl: add VLAN offload set interface
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.
