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.

Sign up for GitHub

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

Jump to bottom

[radv] Rename service unit file Jinja template to radv.service.j2 #1480

Merged
merged 1 commit into from
Mar 10, 2018
Merged

[radv] Rename service unit file Jinja template to radv.service.j2 #1480

merged 1 commit into from
Mar 10, 2018

Conversation

jleveque
Copy link
Contributor

  • Service unit file not getting generated because I changed the docker
    container name from 'router_advertiser' to 'radv', however I didn't
    rename the service unit file template name to match. However,
    slave.mk generates a service file for every docker based on its
    container name, and since there was no matching 'radv.service.j2'
    template file, this file stopped getting generated and therefore
    the docker container was never getting started.

  • Also add swss.service to 'Requires'

@jleveque
[radv] Rename service unit file Jinja template to radv.service.j2
a147f82 
  - Service unit file not getting generated because I changed the docker
    container name from 'router_advertiser' to 'radv', however I didn't
    rename the service unit file template name to match. However,
    slave.mk generates a service file for every docker based on its
    container name, and since there was no matching 'radv.service.j2'
    template file, this file stopped getting generated and therefore
    the docker container was never getting started.

  - Also add swss.service to 'Requires'
@jleveque jleveque self-assigned this Mar 10, 2018
@jleveque jleveque requested a review from taoyl-ms March 10, 2018 01:55
@jleveque jleveque merged commit e6278c1 into sonic-net:master Mar 10, 2018
@jleveque jleveque deleted the radv_service_gen_fix branch March 10, 2018 07:01
stephenxs added a commit to stephenxs/sonic-buildimage that referenced this pull request Dec 3, 2020
@stephenxs
Advance submodule head for sonic-swss and sonic-swss-common
2457d9f 
swss:
- [port_rates][rif_rates] Fix port_rates.lua (sonic-net#1520)
- Improve the way of handling BUFFER_PG during PFC storm (sonic-net#1480)
- [Orchagent] Vxlanorch and Portsorch changes for EVPN VXLAN (sonic-net#1264)
- [sub intf] ecmp hardware convergence acceleration at parent port oper status changes (sonic-net#1492)
- [dvs/copp] Adjust policer checks in VS tests for default COPP policers (sonic-net#1519)
- Flush ARP/neighbor entry on FDB flush when port L2-L3 (sonic-net#1506)
- [intfmgr]: Add GARP support (sonic-net#1503)

swss-common:
- [Dynamic buffer calc] Support dynamic buffer calculation (sonic-net#361)
- README.md: Update build requirements (sonic-net#414)

Signed-off-by: Stephen Sun <stephens@nvidia.com>
@stephenxs stephenxs mentioned this pull request Dec 3, 2020
Merged
3 tasks
daall pushed a commit that referenced this pull request Dec 4, 2020
@stephenxs
Advance submodule head for sonic-swss and sonic-swss-common (#6111)
fdb51e7 
swss:
- [port_rates][rif_rates] Fix port_rates.lua (#1520)
- Improve the way of handling BUFFER_PG during PFC storm (#1480)
- [Orchagent] Vxlanorch and Portsorch changes for EVPN VXLAN (#1264)
- [sub intf] ecmp hardware convergence acceleration at parent port oper status changes (#1492)
- [dvs/copp] Adjust policer checks in VS tests for default COPP policers (#1519)
- Flush ARP/neighbor entry on FDB flush when port L2-L3 (#1506)
- [intfmgr]: Add GARP support (#1503)

swss-common:
- [Dynamic buffer calc] Support dynamic buffer calculation (#361)
- README.md: Update build requirements (#414)

Signed-off-by: Stephen Sun <stephens@nvidia.com>
santhosh-kt pushed a commit to santhosh-kt/sonic-buildimage that referenced this pull request Feb 25, 2021
@stephenxs @santhosh-kt
Advance submodule head for sonic-swss and sonic-swss-common (sonic-ne…
26db3d8 
…t#6111)

swss:
- [port_rates][rif_rates] Fix port_rates.lua (sonic-net#1520)
- Improve the way of handling BUFFER_PG during PFC storm (sonic-net#1480)
- [Orchagent] Vxlanorch and Portsorch changes for EVPN VXLAN (sonic-net#1264)
- [sub intf] ecmp hardware convergence acceleration at parent port oper status changes (sonic-net#1492)
- [dvs/copp] Adjust policer checks in VS tests for default COPP policers (sonic-net#1519)
- Flush ARP/neighbor entry on FDB flush when port L2-L3 (sonic-net#1506)
- [intfmgr]: Add GARP support (sonic-net#1503)

swss-common:
- [Dynamic buffer calc] Support dynamic buffer calculation (sonic-net#361)
- README.md: Update build requirements (sonic-net#414)

Signed-off-by: Stephen Sun <stephens@nvidia.com>
theasianpianist pushed a commit to theasianpianist/sonic-buildimage that referenced this pull request Feb 5, 2022
@stephenxs
Improve the way of handling BUFFER_PG during PFC storm (sonic-net#1480)
053aa15 
* Fix the issue: failed to updating BUFFER_PG during PFC storm

One action for the PFC storm is to set a zero buffer profile on the PG under PFC storm.
The zero buffer won't be removed until the PFC storm has gone.
If the user wants to modify the buffer profile for the PG, the bufferorch will return "task_need_retry".
General speaking it doesn't matter unless that:
- the system can't be warm rebooted until the PFC storm has gone.
- the "task_need_retry" will block the update of the entire BUFFER_PG table from being programmed to ASIC.
In this sense, we need a better solution.

The new solution will:
- record the new profile user wants to apply during PFC storm as the "pending profile" for that PG and return "task_success" if the PG is under PFC storm.
- apply the pending profile once the PG is unlocked.
- the latest pending profile will take effect in case user tries updating the profile for more than 1 times.

Signed-off-by: Stephen Sun <stephens@nvidia.com>

* Address review comments: add a pair of brackets for the if-block

Signed-off-by: Stephen Sun <stephens@nvidia.com>

* Fix ut error

Signed-off-by: Stephen Sun <stephens@nvidia.com>

* Fix typo

Signed-off-by: Stephen Sun <stephens@nvidia.com>
vivekrnv added a commit to vivekrnv/sonic-buildimage that referenced this pull request Aug 26, 2022
@vivekrnv
[PFC_WD] Avoid applying ZeroBuffer Profiles to ingress PG when a PFC …
93af69c 
…storm is detected (sonic-net#2304)

What I did
Avoid dropping traffic that is ingressing the port/pg that is in storm. The code changes in this PR avoid creating the ingress zero pool and profile and does not attach any zero profile to the ingress pg when pfcwd is triggered

Revert changes related to sonic-net#1480 where the retry mechanism was added to BufferOrch which caches the task retries and while the PG is locked by PfcWdZeroBufferHandler.

Revert changes related to sonic-net#2164 in PfcWdZeroBufferHandler & ZeroBufferProfile & BufferOrch.

Updated UT's accordingly

How I verified it
UT's.
Ran the sonic-mgmt test with these changes sonic-net/sonic-mgmt#5665 and verified if they've passed.

Signed-off-by: Vivek Reddy Karri <vkarri@nvidia.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@lguohan lguohan lguohan approved these changes

@taoyl-ms taoyl-ms Awaiting requested review from taoyl-ms

Assignees

@jleveque jleveque

Labels
Bug 🐛
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@jleveque @lguohan