Skip to content
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

Ensure that bmv2 targets are notified in case of config swap #906

Merged
merged 1 commit into from
Jun 5, 2020

Conversation

antoninbas
Copy link
Member

In some case, the do_swap() call in simple_switch never returned 0
(because the swap was performed independently of the target), which
meant that the with_queueing_metadata flag was not updated.

This created an issue in the following specific scenario:

  • simple_switch is started with a JSON config that does not include
    queueing metadata fields
  • a JSON config swap is performed (using the runtime_CLI or P4Runtime,
    in the case of simple_switch_grpc), and the new config includes all
    queueing metadata fields
  • queueing metadata fields still show as 0 for all subsequent traffic

To fix this, we get rid of the assumption that targets are in charge of
calling do_swap() themselves, which must data back to when Packet
instantiation was not guarded by a lock (thus requiring the
collaboration of targets to ensure no new Packets were created as the
swap if being performed).

From now targets are notified using the swap_notify_() virtual method,
which targets can override.

Fixes #905

In some case, the do_swap() call in simple_switch never returned 0
(because the swap was performed independently of the target), which
meant that the with_queueing_metadata flag was not updated.

This created an issue in the following specific scenario:
 * simple_switch is started with a JSON config that does not include
   queueing metadata fields
 * a JSON config swap is performed (using the runtime_CLI or P4Runtime,
   in the case of simple_switch_grpc), and the new config includes all
   queueing metadata fields
 * queueing metadata fields still show as 0 for all subsequent traffic

To fix this, we get rid of the assumption that targets are in charge of
calling do_swap() themselves, which must data back to when Packet
instantiation was not guarded by a lock (thus requiring the
collaboration of targets to ensure no new Packets were created as the
swap if being performed).

From now targets are notified using the swap_notify_() virtual method,
which targets can override.

Fixes #905
@codecov-commenter
Copy link

codecov-commenter commented Jun 5, 2020

Codecov Report

Merging #906 into master will increase coverage by 0.00%.
The diff coverage is 100.00%.

Impacted file tree graph

@@           Coverage Diff           @@
##           master     #906   +/-   ##
=======================================
  Coverage   74.32%   74.32%           
=======================================
  Files         115      115           
  Lines       10243    10247    +4     
=======================================
+ Hits         7613     7616    +3     
- Misses       2630     2631    +1     
Impacted Files Coverage Δ
include/bm/bm_sim/switch.h 1.93% <100.00%> (+0.63%) ⬆️
src/bm_sim/switch.cpp 72.65% <100.00%> (+0.33%) ⬆️
src/bm_sim/learning.cpp 81.67% <0.00%> (-0.39%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 49e9517...39e1984. Read the comment docs.

@antoninbas antoninbas merged commit 498202d into master Jun 5, 2020
@antoninbas antoninbas deleted the antonin/fix-bmv2-target-swap-notification branch June 5, 2020 18:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

zero-valued enq_timestamp and deq_timedelta in egress pipeline
2 participants