Skip to content

net: ethernet: allow receive priority tagged vlan frames without needing a virtual interface #84023

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
clamattia opened this issue Jan 15, 2025 · 0 comments · Fixed by #84873
Closed
Labels
area: Ethernet Enhancement Changes/Updates/Additions to existing features

Comments

@clamattia
Copy link
Collaborator

clamattia commented Jan 15, 2025

Is your enhancement proposal related to a problem? Please describe.
#83662 asks for possibility to receive priority tagged frames. #83734 adds this feature, if the CONFIG_VLAN is enabled. Today CONFIG_VLAN requires CONFIG_VLAN_COUNT>0. If someone wants to receive only id=0 (priority tagged) frames, they do not need an actual virtual interface and would like to safe the RAM and ROM of compiling in vlan.c.

As enhancement, find a way to receive priority tagged frames, without needing an actual virtual interface.

Describe the solution you'd like
User can receive priority tagged frames, without needing the virtual interface sitting there for nothing.

Describe alternatives you've considered

  • priority tagging to be always active, even when CONFIG_VLAN is not activated (see linked PR discussion)
@clamattia clamattia added the Enhancement Changes/Updates/Additions to existing features label Jan 15, 2025
jukkar added a commit to jukkar/zephyr that referenced this issue Jan 30, 2025
If VLAN count is set to 0, then only priority tagged VLAN frames
that have tag value 0 can be received. Also this means that VLAN
interfaces are not created which can save memory if you do not need
to receive any other VLAN frames than those tagged with value 0.

Fixes zephyrproject-rtos#84023

Signed-off-by: Jukka Rissanen <[email protected]>
RuibinChang pushed a commit to RuibinChang/zephyr that referenced this issue Feb 10, 2025
If VLAN count is set to 0, then only priority tagged VLAN frames
that have tag value 0 can be received. Also this means that VLAN
interfaces are not created which can save memory if you do not need
to receive any other VLAN frames than those tagged with value 0.

Fixes zephyrproject-rtos#84023

(cherry picked from commit 9c24578)

Original-Signed-off-by: Jukka Rissanen <[email protected]>
GitOrigin-RevId: 9c24578
Cr-Build-Id: 8724184635785024145
Cr-Build-Url: https://cr-buildbucket.appspot.com/build/8724184635785024145
Copybot-Job-Name: zephyr-main-copybot-downstream
Change-Id: I6aafe41cfed8b78a278661d86438f6b507a3bdc9
Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/third_party/zephyr/+/6222354
Commit-Queue: ChromeOS Prod (Robot) <[email protected]>
Bot-Commit: ChromeOS Prod (Robot) <[email protected]>
Tested-by: ChromeOS Prod (Robot) <[email protected]>
clamattia pushed a commit to endresshauser-lp/zephyr that referenced this issue Mar 6, 2025
If VLAN count is set to 0, then only priority tagged VLAN frames
that have tag value 0 can be received. Also this means that VLAN
interfaces are not created which can save memory if you do not need
to receive any other VLAN frames than those tagged with value 0.

Fixes zephyrproject-rtos#84023

Signed-off-by: Jukka Rissanen <[email protected]>
clamattia pushed a commit to endresshauser-lp/zephyr that referenced this issue Mar 7, 2025
If VLAN count is set to 0, then only priority tagged VLAN frames
that have tag value 0 can be received. Also this means that VLAN
interfaces are not created which can save memory if you do not need
to receive any other VLAN frames than those tagged with value 0.

Fixes zephyrproject-rtos#84023

Signed-off-by: Jukka Rissanen <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: Ethernet Enhancement Changes/Updates/Additions to existing features
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants