Hi Stephen,

Thank you for the review. I really appreciate your insights and the fix.

------------------------------------------------------------------
发件人：Stephen Hemminger <stephen@networkplumber.org>
发送时间：2025年11月27日(周四) 06:16
收件人：Dimon<dimon.zhao@nebula-matrix.com>
抄　送：dev<dev@dpdk.org>; Kyo Liu<kyo.liu@nebula-matrix.com>; Leon<leon.yu@nebula-matrix.com>; Sam<sam.chen@nebula-matrix.com>; techboard<techboard@dpdk.org>
主　题：Re: 回复：回复：[PATCH v1 1/1] net/nbl: add VLAN offload set interface

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.



本邮件所含信息及其任何附件为保密信息且可能属于专有信息。任何非指定接收人均无权访问本邮件。如果您不是该邮件的指定接收人，那么任何对本邮件内容进行披露，复制或使用的行为均是禁止的。如果您不是该邮件的指定接收人，请您立即通过邮件通知 compliance@nebula-matrix.com并立即删除您错误接受的邮件。
The information in this message and any attachments is confidential and may be privileged.  Access to this email by anyone other than the intended recipient is not authorized.  If you are not the intended recipient, disclosure, copying or use of the contents of this email is prohibited.  If you are not the intended recipient, please notify  compliance@nebula-matrix.com immediately by email, and please destroy the email you received in error.