Skip to content

[loganalyzer] Fix the files not copied issue in run_command_with_log_analyzer.yml#963

Merged
liat-grozovik merged 1 commit intosonic-net:masterfrom
wangxin:run-cmd-la
Jun 25, 2019
Merged

[loganalyzer] Fix the files not copied issue in run_command_with_log_analyzer.yml#963
liat-grozovik merged 1 commit intosonic-net:masterfrom
wangxin:run-cmd-la

Conversation

@wangxin
Copy link
Collaborator

@wangxin wangxin commented Jun 17, 2019

The copy files task was after the fail tests. In case of failure, the
copy task would never get a chance to run. This commit
adjusted the task sequence. In case of failure, copy the files, then
fail the test.

The original copy task copies files with deep folder structure.
This issue was also fixed in this commit.

Signed-off-by: Xin Wang [email protected]

Description of PR

Summary:
Fixes # (issue)

Type of change

  • Bug fix
  • [] Testbed and Framework(new/improvement)
  • [] Test case(new/improvement)

Approach

How did you do it?

This commit adjusted the task sequence. In case of failure, copy the files, then fail the test.

How did you verify/test it?

Verified on Mellanox platform.

Any platform specific information?

NA

Supported testbed topology if it's a new test case?

Documentation

…analyzer.yml

The copy files task was after the fail tests. In case of failure, the
copy task would never get a chance to run. This commit
adjusted the task sequence. In case of failure, copy the files, then
fail the test.

The original copy task copies files with deep folder structure.
This issue was also fixed in this commit.

Signed-off-by: Xin Wang <[email protected]>
@liat-grozovik liat-grozovik merged commit 50a19f0 into sonic-net:master Jun 25, 2019
yxieca pushed a commit that referenced this pull request Jul 10, 2019
…analyzer.yml (#963)

The copy files task was after the fail tests. In case of failure, the
copy task would never get a chance to run. This commit
adjusted the task sequence. In case of failure, copy the files, then
fail the test.

The original copy task copies files with deep folder structure.
This issue was also fixed in this commit.

Signed-off-by: Xin Wang <[email protected]>
@wangxin wangxin deleted the run-cmd-la branch September 26, 2019 12:36
fraserg-arista pushed a commit to fraserg-arista/sonic-mgmt that referenced this pull request Feb 24, 2026
…sonic-net#963)

<!--
Please make sure you've read and understood our contributing guidelines;
https://github.com/sonic-net/SONiC/blob/gh-pages/CONTRIBUTING.md

Please provide following information to help code review process a bit easier:
-->
### Description of PR
<!--
- Please include a summary of the change and which issue is fixed.
- Please also include relevant motivation and context. Where should reviewer start? background context?
- List any dependencies that are required for this change.
-->

Summary:
Fixes # (issue)

### Type of change

<!--
- Fill x for your type of change.
- e.g.
- [x] Bug fix
-->

- [x] Bug fix
- [ ] Testbed and Framework(new/improvement)
- [ ] New Test case
 - [ ] Skipped for non-supported platforms
- [ ] Test case improvement

### Back port request
- [ ] 202205
- [ ] 202305
- [ ] 202311
- [ ] 202405
- [ ] 202411
- [x] 202412
- [x] 202505

### Approach
#### What is the motivation for this PR?
Packet trimming verification was failing when using a PortChannel. We found that the current implementation for distributing packets was not working for the th5 chip. Specifically, all the packets that are supposed to fill up the egress queue were going to one of the ports in the LAG, and then the second set of packet that we expect to be trimmed was going to the other port. Therefore, trimming never happened.

#### How did you do it?
Instead of setting the UDP source port to `DEFAULT_SRC_PORT + interface_index` we use `DEFAULT_SRC_PORT + 10 failure_prs.log skip_prs.log interface_index`.

#### How did you verify/test it?
Verified via `tcpdump` that packets were now filling up the egress queue on both ports in the LAG. Also verified that trimming was occurring when sending the second wave of packets.

#### Any platform specific information?
This problem was only discovered when testing with th5

#### Supported testbed topology if it's a new test case?

### Documentation
<!--
(If it's a new feature, new test case)
Did you update documentation/Wiki relevant to your implementation?
Link to the wiki page?
-->
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants