search

netobserv / netobserv-ebpf-agent

Network Observability eBPF Agent
Apache License 2.0
128 stars 33 forks source link

NETOBSERV-1473: migrating netobserv-agent to TCx for new kernels #262

Closed msherif1234 closed 5 months ago

msherif1234 commented 8 months ago

Description

Migrate ebpf agent from TC to TCX "TC eXpress" if the kernel support it, this PR fix #230.

xdp:

tc: wlp0s20f3(2) tcx/ingress tcx_ingress_flow_parse prog_id 3923 link_id 214 wlp0s20f3(2) tcx/egress tcx_egress_flow_parse prog_id 3922 link_id 213 br-68b237cee3d3(3) tcx/ingress tcx_ingress_flow_parse prog_id 3923 link_id 216 br-68b237cee3d3(3) tcx/egress tcx_egress_flow_parse prog_id 3922 link_id 215 docker0(4) tcx/ingress tcx_ingress_flow_parse prog_id 3923 link_id 218 docker0(4) tcx/egress tcx_egress_flow_parse prog_id 3922 link_id 217 enp9s0u2u1u2(1736) tcx/ingress tcx_ingress_flow_parse prog_id 3923 link_id 220 enp9s0u2u1u2(1736) tcx/egress tcx_egress_flow_parse prog_id 3922 link_id 219

flow_dissector:

netfilter:

- testing 
* [X] using `6.6.2-201.fc39.x86_64` run standalone agent code as well as e2e test and both passed with the new TCX. Waiting for OCP build with rhel9.4 to be able to resume the testing on OCP cluster

* [ ] pkt drop
* [ ] DNS
* [ ] RTT
* [ ] SRIOV secondary interface
* [ ] PCA
* [ ] performance and scale test

* [X] on older kernel we will get this warning and fall back to the legacy TC hooks
```sh
time="2024-02-05T12:56:55Z" level=info msg="interface detected. trying to attach TCX hook" component=agent.Flows interface="{1b684d9681b6cb8 106 NS(none)}"
time="2024-02-05T12:56:55Z" level=warning msg="can't attach to TCx hook flow ebpfFetcher. fall back to use legacy TC hook" component=agent.Flows error="failed to attach TCX egress: tcx not supported (requires >= v6.6)" interface="{1b684d9681b6cb8 106 NS(none)}"

Note: GH use ubuntu-latest which is currently 6.2.0 so doesn't have TCX support yet

Dependencies

OCP with rhel9.4 kernel

Checklist

If you are not familiar with our processes or don't know what to answer in the list below, let us know in a comment: the maintainers will take care of that.

openshift-ci-robot commented 8 months ago

@msherif1234: This pull request references NETOBSERV-1408 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the epic to target the "4.16.0" version, but no target version was set.

In response to [this](https://github.com/netobserv/netobserv-ebpf-agent/pull/262): >## Description > > > >## Dependencies > > >n/a > >## Checklist > >If you are not familiar with our processes or don't know what to answer in the list below, let us know in a comment: the maintainers will take care of that. > >* [ ] Will this change affect NetObserv / Network Observability operator? If not, you can ignore the rest of this checklist. >* [ ] Is this PR backed with a JIRA ticket? If so, make sure it is written as a title prefix _(in general, PRs affecting the NetObserv/Network Observability product should be backed with a JIRA ticket - especially if they bring user facing changes)._ >* [ ] Does this PR require product documentation? > * [ ] If so, make sure the JIRA epic is labelled with "documentation" and provides a description relevant for doc writers, such as use cases or scenarios. Any required step to activate or configure the feature should be documented there, such as new CRD knobs. >* [ ] Does this PR require a product release notes entry? > * [ ] If so, fill in "Release Note Text" in the JIRA. >* [ ] Is there anything else the QE team should know before testing? E.g: configuration changes, environment setup, etc. > * [ ] If so, make sure it is described in the JIRA ticket. >* QE requirements (check 1 from the list): > * [ ] Standard QE validation, with pre-merge tests unless stated otherwise. > * [ ] Regression tests only (e.g. refactoring with no user-facing change). > * [ ] No QE (e.g. trivial change with high reviewer's confidence, or per agreement with the QE team). > Instructions for interacting with me using PR comments are available [here](https://prow.ci.openshift.org/command-help?repo=netobserv%2Fnetobserv-ebpf-agent). If you have questions or suggestions related to my behavior, please file an issue against the [openshift-eng/jira-lifecycle-plugin](https://github.com/openshift-eng/jira-lifecycle-plugin/issues/new) repository.
codecov[bot] commented 8 months ago

Codecov Report

Attention: Patch coverage is 1.88679% with 156 lines in your changes are missing coverage. Please review.

Project coverage is 32.96%. Comparing base (08030df) to head (99dc152).

Files Patch % Lines
pkg/ebpf/tracer.go 0.00% 133 Missing :warning:
pkg/agent/packets_agent.go 0.00% 8 Missing :warning:
pkg/ebpf/bpf_x86_bpfel.go 0.00% 8 Missing :warning:
pkg/agent/agent.go 12.50% 6 Missing and 1 partial :warning:
Additional details and impacted files ```diff @@ Coverage Diff @@ ## main #262 +/- ## ========================================== - Coverage 34.04% 32.96% -1.09% ========================================== Files 47 47 Lines 3836 3959 +123 ========================================== - Hits 1306 1305 -1 - Misses 2444 2568 +124 Partials 86 86 ``` | [Flag](https://app.codecov.io/gh/netobserv/netobserv-ebpf-agent/pull/262/flags?src=pr&el=flags&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=netobserv) | Coverage Δ | | |---|---|---| | [unittests](https://app.codecov.io/gh/netobserv/netobserv-ebpf-agent/pull/262/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=netobserv) | `32.96% <1.88%> (-1.09%)` | :arrow_down: | Flags with carried forward coverage won't be shown. [Click here](https://docs.codecov.io/docs/carryforward-flags?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=netobserv#carryforward-flags-in-the-pull-request-comment) to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

openshift-ci-robot commented 8 months ago

@msherif1234: This pull request references NETOBSERV-1408 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the epic to target the "4.16.0" version, but no target version was set.

In response to [this](https://github.com/netobserv/netobserv-ebpf-agent/pull/262): >## Description >how to check TCX is enabled in ur kernel >```sh >zgrep CONFIG_NET_XGRESS /boot/config-$(uname -r) >CONFIG_NET_XGRESS=y >``` > > >## Dependencies > > >n/a > >## Checklist > >If you are not familiar with our processes or don't know what to answer in the list below, let us know in a comment: the maintainers will take care of that. > >* [ ] Will this change affect NetObserv / Network Observability operator? If not, you can ignore the rest of this checklist. >* [ ] Is this PR backed with a JIRA ticket? If so, make sure it is written as a title prefix _(in general, PRs affecting the NetObserv/Network Observability product should be backed with a JIRA ticket - especially if they bring user facing changes)._ >* [ ] Does this PR require product documentation? > * [ ] If so, make sure the JIRA epic is labelled with "documentation" and provides a description relevant for doc writers, such as use cases or scenarios. Any required step to activate or configure the feature should be documented there, such as new CRD knobs. >* [ ] Does this PR require a product release notes entry? > * [ ] If so, fill in "Release Note Text" in the JIRA. >* [ ] Is there anything else the QE team should know before testing? E.g: configuration changes, environment setup, etc. > * [ ] If so, make sure it is described in the JIRA ticket. >* QE requirements (check 1 from the list): > * [ ] Standard QE validation, with pre-merge tests unless stated otherwise. > * [ ] Regression tests only (e.g. refactoring with no user-facing change). > * [ ] No QE (e.g. trivial change with high reviewer's confidence, or per agreement with the QE team). > Instructions for interacting with me using PR comments are available [here](https://prow.ci.openshift.org/command-help?repo=netobserv%2Fnetobserv-ebpf-agent). If you have questions or suggestions related to my behavior, please file an issue against the [openshift-eng/jira-lifecycle-plugin](https://github.com/openshift-eng/jira-lifecycle-plugin/issues/new) repository.
openshift-ci-robot commented 8 months ago

@msherif1234: This pull request references NETOBSERV-1408 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the epic to target the "4.16.0" version, but no target version was set.

In response to [this](https://github.com/netobserv/netobserv-ebpf-agent/pull/262): >## Description >how to check TCX is enabled in ur kernel >```sh >zgrep CONFIG_NET_XGRESS /boot/config-$(uname -r) >CONFIG_NET_XGRESS=y >``` > >testing >on `6.6.2-201.fc39.x86_64` run standalone agent code as well as e2e test and passed with the new TCX waiting for OCP build with rhel9.4 to be able to resume the testing > >* [ ] test with pkt drop >* [ ] test with DNS >* [ ] test with RTT >* [ ] test SRIOV >* [ ] performance and scale test >## Dependencies > > >n/a > >## Checklist > >If you are not familiar with our processes or don't know what to answer in the list below, let us know in a comment: the maintainers will take care of that. > >* [ ] Will this change affect NetObserv / Network Observability operator? If not, you can ignore the rest of this checklist. >* [ ] Is this PR backed with a JIRA ticket? If so, make sure it is written as a title prefix _(in general, PRs affecting the NetObserv/Network Observability product should be backed with a JIRA ticket - especially if they bring user facing changes)._ >* [ ] Does this PR require product documentation? > * [ ] If so, make sure the JIRA epic is labelled with "documentation" and provides a description relevant for doc writers, such as use cases or scenarios. Any required step to activate or configure the feature should be documented there, such as new CRD knobs. >* [ ] Does this PR require a product release notes entry? > * [ ] If so, fill in "Release Note Text" in the JIRA. >* [ ] Is there anything else the QE team should know before testing? E.g: configuration changes, environment setup, etc. > * [ ] If so, make sure it is described in the JIRA ticket. >* QE requirements (check 1 from the list): > * [ ] Standard QE validation, with pre-merge tests unless stated otherwise. > * [ ] Regression tests only (e.g. refactoring with no user-facing change). > * [ ] No QE (e.g. trivial change with high reviewer's confidence, or per agreement with the QE team). > Instructions for interacting with me using PR comments are available [here](https://prow.ci.openshift.org/command-help?repo=netobserv%2Fnetobserv-ebpf-agent). If you have questions or suggestions related to my behavior, please file an issue against the [openshift-eng/jira-lifecycle-plugin](https://github.com/openshift-eng/jira-lifecycle-plugin/issues/new) repository.
msherif1234 commented 8 months ago

/ok-to-test

github-actions[bot] commented 8 months ago

New image: quay.io/netobserv/netobserv-ebpf-agent:d6040fc

It will expire after two weeks.

To deploy this build, run from the operator repo, assuming the operator is running:

USER=netobserv VERSION=d6040fc make set-agent-image
openshift-ci-robot commented 8 months ago

@msherif1234: This pull request references NETOBSERV-1408 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the epic to target the "4.16.0" version, but no target version was set.

In response to [this](https://github.com/netobserv/netobserv-ebpf-agent/pull/262): >## Description >how to check TCX is enabled in ur kernel >```sh >zgrep CONFIG_NET_XGRESS /boot/config-$(uname -r) >CONFIG_NET_XGRESS=y >``` > >testing >on `6.6.2-201.fc39.x86_64` run standalone agent code as well as e2e test and passed with the new TCX waiting for OCP build with rhel9.4 to be able to resume the testing > >* [ ] test with pkt drop >* [ ] test with DNS >* [ ] test with RTT >* [ ] test SRIOV >* [ ] test PCA >* [ ] performance and scale test >## Dependencies > > >n/a > >## Checklist > >If you are not familiar with our processes or don't know what to answer in the list below, let us know in a comment: the maintainers will take care of that. > >* [ ] Will this change affect NetObserv / Network Observability operator? If not, you can ignore the rest of this checklist. >* [ ] Is this PR backed with a JIRA ticket? If so, make sure it is written as a title prefix _(in general, PRs affecting the NetObserv/Network Observability product should be backed with a JIRA ticket - especially if they bring user facing changes)._ >* [ ] Does this PR require product documentation? > * [ ] If so, make sure the JIRA epic is labelled with "documentation" and provides a description relevant for doc writers, such as use cases or scenarios. Any required step to activate or configure the feature should be documented there, such as new CRD knobs. >* [ ] Does this PR require a product release notes entry? > * [ ] If so, fill in "Release Note Text" in the JIRA. >* [ ] Is there anything else the QE team should know before testing? E.g: configuration changes, environment setup, etc. > * [ ] If so, make sure it is described in the JIRA ticket. >* QE requirements (check 1 from the list): > * [ ] Standard QE validation, with pre-merge tests unless stated otherwise. > * [ ] Regression tests only (e.g. refactoring with no user-facing change). > * [ ] No QE (e.g. trivial change with high reviewer's confidence, or per agreement with the QE team). > Instructions for interacting with me using PR comments are available [here](https://prow.ci.openshift.org/command-help?repo=netobserv%2Fnetobserv-ebpf-agent). If you have questions or suggestions related to my behavior, please file an issue against the [openshift-eng/jira-lifecycle-plugin](https://github.com/openshift-eng/jira-lifecycle-plugin/issues/new) repository.
openshift-ci-robot commented 8 months ago

@msherif1234: This pull request references NETOBSERV-1408 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the epic to target the "4.16.0" version, but no target version was set.

In response to [this](https://github.com/netobserv/netobserv-ebpf-agent/pull/262): >## Description >how to check TCX is enabled in ur kernel >```sh >zgrep CONFIG_NET_XGRESS /boot/config-$(uname -r) >CONFIG_NET_XGRESS=y >``` > >testing >on `6.6.2-201.fc39.x86_64` run standalone agent code as well as e2e test and passed with the new TCX waiting for OCP build with rhel9.4 to be able to resume the testing > >* [ ] test with pkt drop >* [ ] test with DNS >* [ ] test with RTT >* [ ] test SRIOV >* [ ] test PCA >* [ ] performance and scale test > >on older kernel we will get this warning and fall back to the legacy TC hooks >```sh >time="2024-02-05T12:56:55Z" level=info msg="interface detected. trying to attach TCX hook" component=agent.Flows interface="{1b684d9681b6cb8 106 NS(none)}" >time="2024-02-05T12:56:55Z" level=warning msg="can't attach to TCx hook flow ebpfFetcher. fall back to use legacy TC hook" component=agent.Flows error="failed to attach TCX egress: tcx not supported (requires >= v6.6)" interface="{1b684d9681b6cb8 106 NS(none)}" >``` >## Dependencies > > >n/a > >## Checklist > >If you are not familiar with our processes or don't know what to answer in the list below, let us know in a comment: the maintainers will take care of that. > >* [ ] Will this change affect NetObserv / Network Observability operator? If not, you can ignore the rest of this checklist. >* [ ] Is this PR backed with a JIRA ticket? If so, make sure it is written as a title prefix _(in general, PRs affecting the NetObserv/Network Observability product should be backed with a JIRA ticket - especially if they bring user facing changes)._ >* [ ] Does this PR require product documentation? > * [ ] If so, make sure the JIRA epic is labelled with "documentation" and provides a description relevant for doc writers, such as use cases or scenarios. Any required step to activate or configure the feature should be documented there, such as new CRD knobs. >* [ ] Does this PR require a product release notes entry? > * [ ] If so, fill in "Release Note Text" in the JIRA. >* [ ] Is there anything else the QE team should know before testing? E.g: configuration changes, environment setup, etc. > * [ ] If so, make sure it is described in the JIRA ticket. >* QE requirements (check 1 from the list): > * [ ] Standard QE validation, with pre-merge tests unless stated otherwise. > * [ ] Regression tests only (e.g. refactoring with no user-facing change). > * [ ] No QE (e.g. trivial change with high reviewer's confidence, or per agreement with the QE team). > Instructions for interacting with me using PR comments are available [here](https://prow.ci.openshift.org/command-help?repo=netobserv%2Fnetobserv-ebpf-agent). If you have questions or suggestions related to my behavior, please file an issue against the [openshift-eng/jira-lifecycle-plugin](https://github.com/openshift-eng/jira-lifecycle-plugin/issues/new) repository.
openshift-ci-robot commented 8 months ago

@msherif1234: This pull request references NETOBSERV-1408 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the epic to target the "4.16.0" version, but no target version was set.

In response to [this](https://github.com/netobserv/netobserv-ebpf-agent/pull/262): >## Description >how to check TCX is enabled in ur kernel >```sh >zgrep CONFIG_NET_XGRESS /boot/config-$(uname -r) >CONFIG_NET_XGRESS=y >``` > >testing >on `6.6.2-201.fc39.x86_64` run standalone agent code as well as e2e test and passed with the new TCX waiting for OCP build with rhel9.4 to be able to resume the testing > >* [ ] test with pkt drop >* [ ] test with DNS >* [ ] test with RTT >* [ ] test SRIOV >* [ ] test PCA >* [ ] performance and scale test > >on older kernel we will get this warning and fall back to the legacy TC hooks >```sh >time="2024-02-05T12:56:55Z" level=info msg="interface detected. trying to attach TCX hook" component=agent.Flows interface="{1b684d9681b6cb8 106 NS(none)}" >time="2024-02-05T12:56:55Z" level=warning msg="can't attach to TCx hook flow ebpfFetcher. fall back to use legacy TC hook" component=agent.Flows error="failed to attach TCX egress: tcx not supported (requires >= v6.6)" interface="{1b684d9681b6cb8 106 NS(none)}" >``` > >fix #230 >## Dependencies > > >n/a > >## Checklist > >If you are not familiar with our processes or don't know what to answer in the list below, let us know in a comment: the maintainers will take care of that. > >* [ ] Will this change affect NetObserv / Network Observability operator? If not, you can ignore the rest of this checklist. >* [ ] Is this PR backed with a JIRA ticket? If so, make sure it is written as a title prefix _(in general, PRs affecting the NetObserv/Network Observability product should be backed with a JIRA ticket - especially if they bring user facing changes)._ >* [ ] Does this PR require product documentation? > * [ ] If so, make sure the JIRA epic is labelled with "documentation" and provides a description relevant for doc writers, such as use cases or scenarios. Any required step to activate or configure the feature should be documented there, such as new CRD knobs. >* [ ] Does this PR require a product release notes entry? > * [ ] If so, fill in "Release Note Text" in the JIRA. >* [ ] Is there anything else the QE team should know before testing? E.g: configuration changes, environment setup, etc. > * [ ] If so, make sure it is described in the JIRA ticket. >* QE requirements (check 1 from the list): > * [ ] Standard QE validation, with pre-merge tests unless stated otherwise. > * [ ] Regression tests only (e.g. refactoring with no user-facing change). > * [ ] No QE (e.g. trivial change with high reviewer's confidence, or per agreement with the QE team). > Instructions for interacting with me using PR comments are available [here](https://prow.ci.openshift.org/command-help?repo=netobserv%2Fnetobserv-ebpf-agent). If you have questions or suggestions related to my behavior, please file an issue against the [openshift-eng/jira-lifecycle-plugin](https://github.com/openshift-eng/jira-lifecycle-plugin/issues/new) repository.
openshift-ci-robot commented 8 months ago

@msherif1234: This pull request references NETOBSERV-1408 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the epic to target the "4.16.0" version, but no target version was set.

In response to [this](https://github.com/netobserv/netobserv-ebpf-agent/pull/262): >## Description >how to check TCX is enabled in ur kernel >```sh >zgrep CONFIG_NET_XGRESS /boot/config-$(uname -r) >CONFIG_NET_XGRESS=y >``` > >testing >on `6.6.2-201.fc39.x86_64` run standalone agent code as well as e2e test and passed with the new TCX waiting for OCP build with rhel9.4 to be able to resume the testing > >* [ ] pkt drop >* [ ] DNS >* [ ] RTT >* [ ] SRIOV secondary interface >* [ ] PCA >* [ ] performance and scale test > >on older kernel we will get this warning and fall back to the legacy TC hooks >```sh >time="2024-02-05T12:56:55Z" level=info msg="interface detected. trying to attach TCX hook" component=agent.Flows interface="{1b684d9681b6cb8 106 NS(none)}" >time="2024-02-05T12:56:55Z" level=warning msg="can't attach to TCx hook flow ebpfFetcher. fall back to use legacy TC hook" component=agent.Flows error="failed to attach TCX egress: tcx not supported (requires >= v6.6)" interface="{1b684d9681b6cb8 106 NS(none)}" >``` > >fix #230 >## Dependencies > > >n/a > >## Checklist > >If you are not familiar with our processes or don't know what to answer in the list below, let us know in a comment: the maintainers will take care of that. > >* [ ] Will this change affect NetObserv / Network Observability operator? If not, you can ignore the rest of this checklist. >* [ ] Is this PR backed with a JIRA ticket? If so, make sure it is written as a title prefix _(in general, PRs affecting the NetObserv/Network Observability product should be backed with a JIRA ticket - especially if they bring user facing changes)._ >* [ ] Does this PR require product documentation? > * [ ] If so, make sure the JIRA epic is labelled with "documentation" and provides a description relevant for doc writers, such as use cases or scenarios. Any required step to activate or configure the feature should be documented there, such as new CRD knobs. >* [ ] Does this PR require a product release notes entry? > * [ ] If so, fill in "Release Note Text" in the JIRA. >* [ ] Is there anything else the QE team should know before testing? E.g: configuration changes, environment setup, etc. > * [ ] If so, make sure it is described in the JIRA ticket. >* QE requirements (check 1 from the list): > * [ ] Standard QE validation, with pre-merge tests unless stated otherwise. > * [ ] Regression tests only (e.g. refactoring with no user-facing change). > * [ ] No QE (e.g. trivial change with high reviewer's confidence, or per agreement with the QE team). > Instructions for interacting with me using PR comments are available [here](https://prow.ci.openshift.org/command-help?repo=netobserv%2Fnetobserv-ebpf-agent). If you have questions or suggestions related to my behavior, please file an issue against the [openshift-eng/jira-lifecycle-plugin](https://github.com/openshift-eng/jira-lifecycle-plugin/issues/new) repository.
openshift-ci-robot commented 8 months ago

@msherif1234: This pull request references NETOBSERV-1408 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the epic to target the "4.16.0" version, but no target version was set.

In response to [this](https://github.com/netobserv/netobserv-ebpf-agent/pull/262): >## Description >how to check TCX is enabled in ur kernel >```sh >zgrep CONFIG_NET_XGRESS /boot/config-$(uname -r) >CONFIG_NET_XGRESS=y >``` > >testing >on `6.6.2-201.fc39.x86_64` run standalone agent code as well as e2e test and passed with the new TCX waiting for OCP build with rhel9.4 to be able to resume the testing > >* [ ] pkt drop >* [ ] DNS >* [ ] RTT >* [ ] SRIOV secondary interface >* [ ] PCA >* [ ] performance and scale test > >on older kernel we will get this warning and fall back to the legacy TC hooks >```sh >time="2024-02-05T12:56:55Z" level=info msg="interface detected. trying to attach TCX hook" component=agent.Flows interface="{1b684d9681b6cb8 106 NS(none)}" >time="2024-02-05T12:56:55Z" level=warning msg="can't attach to TCx hook flow ebpfFetcher. fall back to use legacy TC hook" component=agent.Flows error="failed to attach TCX egress: tcx not supported (requires >= v6.6)" interface="{1b684d9681b6cb8 106 NS(none)}" >``` > >fix #230 >## Dependencies > >OCP with rhel9.4 kernel > >## Checklist > >If you are not familiar with our processes or don't know what to answer in the list below, let us know in a comment: the maintainers will take care of that. > >* [ ] Will this change affect NetObserv / Network Observability operator? If not, you can ignore the rest of this checklist. >* [X] Is this PR backed with a JIRA ticket? If so, make sure it is written as a title prefix _(in general, PRs affecting the NetObserv/Network Observability product should be backed with a JIRA ticket - especially if they bring user facing changes)._ >* [X] Does this PR require product documentation? > * [ ] If so, make sure the JIRA epic is labelled with "documentation" and provides a description relevant for doc writers, such as use cases or scenarios. Any required step to activate or configure the feature should be documented there, such as new CRD knobs. >* [ ] Does this PR require a product release notes entry? > * [ ] If so, fill in "Release Note Text" in the JIRA. >* [ ] Is there anything else the QE team should know before testing? E.g: configuration changes, environment setup, etc. > * [ ] If so, make sure it is described in the JIRA ticket. >* QE requirements (check 1 from the list): > * [X] Standard QE validation, with pre-merge tests unless stated otherwise. > * [ ] Regression tests only (e.g. refactoring with no user-facing change). > * [ ] No QE (e.g. trivial change with high reviewer's confidence, or per agreement with the QE team). > Instructions for interacting with me using PR comments are available [here](https://prow.ci.openshift.org/command-help?repo=netobserv%2Fnetobserv-ebpf-agent). If you have questions or suggestions related to my behavior, please file an issue against the [openshift-eng/jira-lifecycle-plugin](https://github.com/openshift-eng/jira-lifecycle-plugin/issues/new) repository.
openshift-ci-robot commented 8 months ago

@msherif1234: This pull request references NETOBSERV-1408 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the epic to target the "4.16.0" version, but no target version was set.

In response to [this](https://github.com/netobserv/netobserv-ebpf-agent/pull/262): >## Description >Migrate ebpf agent from TC hooks to TCX is the kernel support it, this PR fix #230. > >- how to check TCX is enabled in ur kernel >```sh >zgrep CONFIG_NET_XGRESS /boot/config-$(uname -r) >CONFIG_NET_XGRESS=y >``` > >- testing >on `6.6.2-201.fc39.x86_64` run standalone agent code as well as e2e test and passed with the new TCX waiting for OCP build with rhel9.4 to be able to resume the testing > >* [ ] pkt drop >* [ ] DNS >* [ ] RTT >* [ ] SRIOV secondary interface >* [ ] PCA >* [ ] performance and scale test > >on older kernel we will get this warning and fall back to the legacy TC hooks >```sh >time="2024-02-05T12:56:55Z" level=info msg="interface detected. trying to attach TCX hook" component=agent.Flows interface="{1b684d9681b6cb8 106 NS(none)}" >time="2024-02-05T12:56:55Z" level=warning msg="can't attach to TCx hook flow ebpfFetcher. fall back to use legacy TC hook" component=agent.Flows error="failed to attach TCX egress: tcx not supported (requires >= v6.6)" interface="{1b684d9681b6cb8 106 NS(none)}" >``` > >## Dependencies > >OCP with rhel9.4 kernel > >## Checklist > >If you are not familiar with our processes or don't know what to answer in the list below, let us know in a comment: the maintainers will take care of that. > >* [ ] Will this change affect NetObserv / Network Observability operator? If not, you can ignore the rest of this checklist. >* [X] Is this PR backed with a JIRA ticket? If so, make sure it is written as a title prefix _(in general, PRs affecting the NetObserv/Network Observability product should be backed with a JIRA ticket - especially if they bring user facing changes)._ >* [X] Does this PR require product documentation? > * [ ] If so, make sure the JIRA epic is labelled with "documentation" and provides a description relevant for doc writers, such as use cases or scenarios. Any required step to activate or configure the feature should be documented there, such as new CRD knobs. >* [ ] Does this PR require a product release notes entry? > * [ ] If so, fill in "Release Note Text" in the JIRA. >* [ ] Is there anything else the QE team should know before testing? E.g: configuration changes, environment setup, etc. > * [ ] If so, make sure it is described in the JIRA ticket. >* QE requirements (check 1 from the list): > * [X] Standard QE validation, with pre-merge tests unless stated otherwise. > * [ ] Regression tests only (e.g. refactoring with no user-facing change). > * [ ] No QE (e.g. trivial change with high reviewer's confidence, or per agreement with the QE team). > Instructions for interacting with me using PR comments are available [here](https://prow.ci.openshift.org/command-help?repo=netobserv%2Fnetobserv-ebpf-agent). If you have questions or suggestions related to my behavior, please file an issue against the [openshift-eng/jira-lifecycle-plugin](https://github.com/openshift-eng/jira-lifecycle-plugin/issues/new) repository.
openshift-ci-robot commented 8 months ago

@msherif1234: This pull request references NETOBSERV-1408 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the epic to target the "4.16.0" version, but no target version was set.

In response to [this](https://github.com/netobserv/netobserv-ebpf-agent/pull/262): >## Description >Migrate ebpf agent from TC hooks to TCX is the kernel support it, this PR fix #230. > >- how to check TCX is enabled in ur kernel >```sh >zgrep CONFIG_NET_XGRESS /boot/config-$(uname -r) >CONFIG_NET_XGRESS=y >``` > >- testing >* [X] using `6.6.2-201.fc39.x86_64` run standalone agent code as well as e2e test and both passed with the new TCX. Waiting for OCP build with rhel9.4 to be able to resume the testing on OCP cluster > >* [ ] pkt drop >* [ ] DNS >* [ ] RTT >* [ ] SRIOV secondary interface >* [ ] PCA >* [ ] performance and scale test > >- on older kernel we will get this warning and fall back to the legacy TC hooks >```sh >time="2024-02-05T12:56:55Z" level=info msg="interface detected. trying to attach TCX hook" component=agent.Flows interface="{1b684d9681b6cb8 106 NS(none)}" >time="2024-02-05T12:56:55Z" level=warning msg="can't attach to TCx hook flow ebpfFetcher. fall back to use legacy TC hook" component=agent.Flows error="failed to attach TCX egress: tcx not supported (requires >= v6.6)" interface="{1b684d9681b6cb8 106 NS(none)}" >``` > >## Dependencies > >OCP with rhel9.4 kernel > >## Checklist > >If you are not familiar with our processes or don't know what to answer in the list below, let us know in a comment: the maintainers will take care of that. > >* [ ] Will this change affect NetObserv / Network Observability operator? If not, you can ignore the rest of this checklist. >* [X] Is this PR backed with a JIRA ticket? If so, make sure it is written as a title prefix _(in general, PRs affecting the NetObserv/Network Observability product should be backed with a JIRA ticket - especially if they bring user facing changes)._ >* [X] Does this PR require product documentation? > * [ ] If so, make sure the JIRA epic is labelled with "documentation" and provides a description relevant for doc writers, such as use cases or scenarios. Any required step to activate or configure the feature should be documented there, such as new CRD knobs. >* [ ] Does this PR require a product release notes entry? > * [ ] If so, fill in "Release Note Text" in the JIRA. >* [ ] Is there anything else the QE team should know before testing? E.g: configuration changes, environment setup, etc. > * [ ] If so, make sure it is described in the JIRA ticket. >* QE requirements (check 1 from the list): > * [X] Standard QE validation, with pre-merge tests unless stated otherwise. > * [ ] Regression tests only (e.g. refactoring with no user-facing change). > * [ ] No QE (e.g. trivial change with high reviewer's confidence, or per agreement with the QE team). > Instructions for interacting with me using PR comments are available [here](https://prow.ci.openshift.org/command-help?repo=netobserv%2Fnetobserv-ebpf-agent). If you have questions or suggestions related to my behavior, please file an issue against the [openshift-eng/jira-lifecycle-plugin](https://github.com/openshift-eng/jira-lifecycle-plugin/issues/new) repository.
openshift-ci-robot commented 8 months ago

@msherif1234: This pull request references NETOBSERV-1408 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the epic to target the "4.16.0" version, but no target version was set.

In response to [this](https://github.com/netobserv/netobserv-ebpf-agent/pull/262): >## Description >Migrate ebpf agent from TC to TCX "TC eXpress" if the kernel support it, this PR fix #230. > >- how to check TCX is enabled in ur kernel >```sh >zgrep CONFIG_NET_XGRESS /boot/config-$(uname -r) >CONFIG_NET_XGRESS=y >``` > >- testing >* [X] using `6.6.2-201.fc39.x86_64` run standalone agent code as well as e2e test and both passed with the new TCX. Waiting for OCP build with rhel9.4 to be able to resume the testing on OCP cluster > >* [ ] pkt drop >* [ ] DNS >* [ ] RTT >* [ ] SRIOV secondary interface >* [ ] PCA >* [ ] performance and scale test > >- on older kernel we will get this warning and fall back to the legacy TC hooks >```sh >time="2024-02-05T12:56:55Z" level=info msg="interface detected. trying to attach TCX hook" component=agent.Flows interface="{1b684d9681b6cb8 106 NS(none)}" >time="2024-02-05T12:56:55Z" level=warning msg="can't attach to TCx hook flow ebpfFetcher. fall back to use legacy TC hook" component=agent.Flows error="failed to attach TCX egress: tcx not supported (requires >= v6.6)" interface="{1b684d9681b6cb8 106 NS(none)}" >``` > >## Dependencies > >OCP with rhel9.4 kernel > >## Checklist > >If you are not familiar with our processes or don't know what to answer in the list below, let us know in a comment: the maintainers will take care of that. > >* [ ] Will this change affect NetObserv / Network Observability operator? If not, you can ignore the rest of this checklist. >* [X] Is this PR backed with a JIRA ticket? If so, make sure it is written as a title prefix _(in general, PRs affecting the NetObserv/Network Observability product should be backed with a JIRA ticket - especially if they bring user facing changes)._ >* [X] Does this PR require product documentation? > * [ ] If so, make sure the JIRA epic is labelled with "documentation" and provides a description relevant for doc writers, such as use cases or scenarios. Any required step to activate or configure the feature should be documented there, such as new CRD knobs. >* [ ] Does this PR require a product release notes entry? > * [ ] If so, fill in "Release Note Text" in the JIRA. >* [ ] Is there anything else the QE team should know before testing? E.g: configuration changes, environment setup, etc. > * [ ] If so, make sure it is described in the JIRA ticket. >* QE requirements (check 1 from the list): > * [X] Standard QE validation, with pre-merge tests unless stated otherwise. > * [ ] Regression tests only (e.g. refactoring with no user-facing change). > * [ ] No QE (e.g. trivial change with high reviewer's confidence, or per agreement with the QE team). > Instructions for interacting with me using PR comments are available [here](https://prow.ci.openshift.org/command-help?repo=netobserv%2Fnetobserv-ebpf-agent). If you have questions or suggestions related to my behavior, please file an issue against the [openshift-eng/jira-lifecycle-plugin](https://github.com/openshift-eng/jira-lifecycle-plugin/issues/new) repository.
openshift-ci-robot commented 8 months ago

@msherif1234: This pull request references NETOBSERV-1408 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the epic to target the "4.16.0" version, but no target version was set.

In response to [this](https://github.com/netobserv/netobserv-ebpf-agent/pull/262): >## Description >Migrate ebpf agent from TC to TCX "TC eXpress" if the kernel support it, this PR fix #230. > >- how to check TCX is enabled in ur kernel >```sh >zgrep CONFIG_NET_XGRESS /boot/config-$(uname -r) >CONFIG_NET_XGRESS=y >``` >- how to check if TCX hooks are attached to all interfaces >```sh >sudo bpftool net > >xdp: > >tc: >wlp0s20f3(2) tcx/ingress tcx_ingress_flow_parse prog_id 3923 link_id 214 >wlp0s20f3(2) tcx/egress tcx_egress_flow_parse prog_id 3922 link_id 213 >br-68b237cee3d3(3) tcx/ingress tcx_ingress_flow_parse prog_id 3923 link_id 216 >br-68b237cee3d3(3) tcx/egress tcx_egress_flow_parse prog_id 3922 link_id 215 >docker0(4) tcx/ingress tcx_ingress_flow_parse prog_id 3923 link_id 218 >docker0(4) tcx/egress tcx_egress_flow_parse prog_id 3922 link_id 217 >enp9s0u2u1u2(1736) tcx/ingress tcx_ingress_flow_parse prog_id 3923 link_id 220 >enp9s0u2u1u2(1736) tcx/egress tcx_egress_flow_parse prog_id 3922 link_id 219 > >flow_dissector: > >netfilter: > >``` >- testing >* [X] using `6.6.2-201.fc39.x86_64` run standalone agent code as well as e2e test and both passed with the new TCX. Waiting for OCP build with rhel9.4 to be able to resume the testing on OCP cluster > >* [ ] pkt drop >* [ ] DNS >* [ ] RTT >* [ ] SRIOV secondary interface >* [ ] PCA >* [ ] performance and scale test > >- on older kernel we will get this warning and fall back to the legacy TC hooks >```sh >time="2024-02-05T12:56:55Z" level=info msg="interface detected. trying to attach TCX hook" component=agent.Flows interface="{1b684d9681b6cb8 106 NS(none)}" >time="2024-02-05T12:56:55Z" level=warning msg="can't attach to TCx hook flow ebpfFetcher. fall back to use legacy TC hook" component=agent.Flows error="failed to attach TCX egress: tcx not supported (requires >= v6.6)" interface="{1b684d9681b6cb8 106 NS(none)}" >``` > >## Dependencies > >OCP with rhel9.4 kernel > >## Checklist > >If you are not familiar with our processes or don't know what to answer in the list below, let us know in a comment: the maintainers will take care of that. > >* [ ] Will this change affect NetObserv / Network Observability operator? If not, you can ignore the rest of this checklist. >* [X] Is this PR backed with a JIRA ticket? If so, make sure it is written as a title prefix _(in general, PRs affecting the NetObserv/Network Observability product should be backed with a JIRA ticket - especially if they bring user facing changes)._ >* [X] Does this PR require product documentation? > * [ ] If so, make sure the JIRA epic is labelled with "documentation" and provides a description relevant for doc writers, such as use cases or scenarios. Any required step to activate or configure the feature should be documented there, such as new CRD knobs. >* [ ] Does this PR require a product release notes entry? > * [ ] If so, fill in "Release Note Text" in the JIRA. >* [ ] Is there anything else the QE team should know before testing? E.g: configuration changes, environment setup, etc. > * [ ] If so, make sure it is described in the JIRA ticket. >* QE requirements (check 1 from the list): > * [X] Standard QE validation, with pre-merge tests unless stated otherwise. > * [ ] Regression tests only (e.g. refactoring with no user-facing change). > * [ ] No QE (e.g. trivial change with high reviewer's confidence, or per agreement with the QE team). > Instructions for interacting with me using PR comments are available [here](https://prow.ci.openshift.org/command-help?repo=netobserv%2Fnetobserv-ebpf-agent). If you have questions or suggestions related to my behavior, please file an issue against the [openshift-eng/jira-lifecycle-plugin](https://github.com/openshift-eng/jira-lifecycle-plugin/issues/new) repository.
openshift-ci-robot commented 8 months ago

@msherif1234: This pull request references NETOBSERV-1408 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the epic to target the "4.16.0" version, but no target version was set.

In response to [this](https://github.com/netobserv/netobserv-ebpf-agent/pull/262): >## Description >Migrate ebpf agent from TC to TCX "TC eXpress" if the kernel support it, this PR fix #230. > >- how to check TCX is enabled in ur kernel >```sh >zgrep CONFIG_NET_XGRESS /boot/config-$(uname -r) >CONFIG_NET_XGRESS=y >``` >- how to check if TCX hooks are attached to all interfaces >```sh >sudo bpftool net > >xdp: > >tc: >wlp0s20f3(2) tcx/ingress tcx_ingress_flow_parse prog_id 3923 link_id 214 >wlp0s20f3(2) tcx/egress tcx_egress_flow_parse prog_id 3922 link_id 213 >br-68b237cee3d3(3) tcx/ingress tcx_ingress_flow_parse prog_id 3923 link_id 216 >br-68b237cee3d3(3) tcx/egress tcx_egress_flow_parse prog_id 3922 link_id 215 >docker0(4) tcx/ingress tcx_ingress_flow_parse prog_id 3923 link_id 218 >docker0(4) tcx/egress tcx_egress_flow_parse prog_id 3922 link_id 217 >enp9s0u2u1u2(1736) tcx/ingress tcx_ingress_flow_parse prog_id 3923 link_id 220 >enp9s0u2u1u2(1736) tcx/egress tcx_egress_flow_parse prog_id 3922 link_id 219 > >flow_dissector: > >netfilter: > >``` >- testing >* [X] using `6.6.2-201.fc39.x86_64` run standalone agent code as well as e2e test and both passed with the new TCX. Waiting for OCP build with rhel9.4 to be able to resume the testing on OCP cluster > >* [ ] pkt drop >* [ ] DNS >* [ ] RTT >* [ ] SRIOV secondary interface >* [ ] PCA >* [ ] performance and scale test > >* [X] on older kernel we will get this warning and fall back to the legacy TC hooks >```sh >time="2024-02-05T12:56:55Z" level=info msg="interface detected. trying to attach TCX hook" component=agent.Flows interface="{1b684d9681b6cb8 106 NS(none)}" >time="2024-02-05T12:56:55Z" level=warning msg="can't attach to TCx hook flow ebpfFetcher. fall back to use legacy TC hook" component=agent.Flows error="failed to attach TCX egress: tcx not supported (requires >= v6.6)" interface="{1b684d9681b6cb8 106 NS(none)}" >``` > >## Dependencies > >OCP with rhel9.4 kernel > >## Checklist > >If you are not familiar with our processes or don't know what to answer in the list below, let us know in a comment: the maintainers will take care of that. > >* [ ] Will this change affect NetObserv / Network Observability operator? If not, you can ignore the rest of this checklist. >* [X] Is this PR backed with a JIRA ticket? If so, make sure it is written as a title prefix _(in general, PRs affecting the NetObserv/Network Observability product should be backed with a JIRA ticket - especially if they bring user facing changes)._ >* [X] Does this PR require product documentation? > * [ ] If so, make sure the JIRA epic is labelled with "documentation" and provides a description relevant for doc writers, such as use cases or scenarios. Any required step to activate or configure the feature should be documented there, such as new CRD knobs. >* [ ] Does this PR require a product release notes entry? > * [ ] If so, fill in "Release Note Text" in the JIRA. >* [ ] Is there anything else the QE team should know before testing? E.g: configuration changes, environment setup, etc. > * [ ] If so, make sure it is described in the JIRA ticket. >* QE requirements (check 1 from the list): > * [X] Standard QE validation, with pre-merge tests unless stated otherwise. > * [ ] Regression tests only (e.g. refactoring with no user-facing change). > * [ ] No QE (e.g. trivial change with high reviewer's confidence, or per agreement with the QE team). > Instructions for interacting with me using PR comments are available [here](https://prow.ci.openshift.org/command-help?repo=netobserv%2Fnetobserv-ebpf-agent). If you have questions or suggestions related to my behavior, please file an issue against the [openshift-eng/jira-lifecycle-plugin](https://github.com/openshift-eng/jira-lifecycle-plugin/issues/new) repository.
openshift-ci-robot commented 8 months ago

@msherif1234: This pull request references NETOBSERV-1408 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the epic to target the "4.16.0" version, but no target version was set.

In response to [this](https://github.com/netobserv/netobserv-ebpf-agent/pull/262): >## Description >Migrate ebpf agent from TC to TCX "TC eXpress" if the kernel support it, this PR fix #230. > >- how to check TCX is enabled in ur kernel >```sh >zgrep CONFIG_NET_XGRESS /boot/config-$(uname -r) >CONFIG_NET_XGRESS=y >``` >- how to check if TCX hooks are attached to all interfaces >```sh >sudo bpftool net > >xdp: > >tc: >wlp0s20f3(2) tcx/ingress tcx_ingress_flow_parse prog_id 3923 link_id 214 >wlp0s20f3(2) tcx/egress tcx_egress_flow_parse prog_id 3922 link_id 213 >br-68b237cee3d3(3) tcx/ingress tcx_ingress_flow_parse prog_id 3923 link_id 216 >br-68b237cee3d3(3) tcx/egress tcx_egress_flow_parse prog_id 3922 link_id 215 >docker0(4) tcx/ingress tcx_ingress_flow_parse prog_id 3923 link_id 218 >docker0(4) tcx/egress tcx_egress_flow_parse prog_id 3922 link_id 217 >enp9s0u2u1u2(1736) tcx/ingress tcx_ingress_flow_parse prog_id 3923 link_id 220 >enp9s0u2u1u2(1736) tcx/egress tcx_egress_flow_parse prog_id 3922 link_id 219 > >flow_dissector: > >netfilter: > >``` >- testing >* [X] using `6.6.2-201.fc39.x86_64` run standalone agent code as well as e2e test and both passed with the new TCX. Waiting for OCP build with rhel9.4 to be able to resume the testing on OCP cluster > >* [ ] pkt drop >* [ ] DNS >* [ ] RTT >* [ ] SRIOV secondary interface >* [ ] PCA >* [ ] performance and scale test > >* [X] on older kernel we will get this warning and fall back to the legacy TC hooks >```sh >time="2024-02-05T12:56:55Z" level=info msg="interface detected. trying to attach TCX hook" component=agent.Flows interface="{1b684d9681b6cb8 106 NS(none)}" >time="2024-02-05T12:56:55Z" level=warning msg="can't attach to TCx hook flow ebpfFetcher. fall back to use legacy TC hook" component=agent.Flows error="failed to attach TCX egress: tcx not supported (requires >= v6.6)" interface="{1b684d9681b6cb8 106 NS(none)}" >``` >Note: GH use `ubuntu-latest` which is currently `6.2.0` so doesn't have TCX support yet >## Dependencies > >OCP with rhel9.4 kernel > >## Checklist > >If you are not familiar with our processes or don't know what to answer in the list below, let us know in a comment: the maintainers will take care of that. > >* [ ] Will this change affect NetObserv / Network Observability operator? If not, you can ignore the rest of this checklist. >* [X] Is this PR backed with a JIRA ticket? If so, make sure it is written as a title prefix _(in general, PRs affecting the NetObserv/Network Observability product should be backed with a JIRA ticket - especially if they bring user facing changes)._ >* [X] Does this PR require product documentation? > * [ ] If so, make sure the JIRA epic is labelled with "documentation" and provides a description relevant for doc writers, such as use cases or scenarios. Any required step to activate or configure the feature should be documented there, such as new CRD knobs. >* [ ] Does this PR require a product release notes entry? > * [ ] If so, fill in "Release Note Text" in the JIRA. >* [ ] Is there anything else the QE team should know before testing? E.g: configuration changes, environment setup, etc. > * [ ] If so, make sure it is described in the JIRA ticket. >* QE requirements (check 1 from the list): > * [X] Standard QE validation, with pre-merge tests unless stated otherwise. > * [ ] Regression tests only (e.g. refactoring with no user-facing change). > * [ ] No QE (e.g. trivial change with high reviewer's confidence, or per agreement with the QE team). > Instructions for interacting with me using PR comments are available [here](https://prow.ci.openshift.org/command-help?repo=netobserv%2Fnetobserv-ebpf-agent). If you have questions or suggestions related to my behavior, please file an issue against the [openshift-eng/jira-lifecycle-plugin](https://github.com/openshift-eng/jira-lifecycle-plugin/issues/new) repository.
openshift-ci-robot commented 8 months ago

@msherif1234: This pull request references NETOBSERV-1473 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.16.0" version, but no target version was set.

In response to [this](https://github.com/netobserv/netobserv-ebpf-agent/pull/262): >## Description >Migrate ebpf agent from TC to TCX "TC eXpress" if the kernel support it, this PR fix #230. > >- how to check TCX is enabled in ur kernel >```sh >zgrep CONFIG_NET_XGRESS /boot/config-$(uname -r) >CONFIG_NET_XGRESS=y >``` >- how to check if TCX hooks are attached to all interfaces >```sh >sudo bpftool net > >xdp: > >tc: >wlp0s20f3(2) tcx/ingress tcx_ingress_flow_parse prog_id 3923 link_id 214 >wlp0s20f3(2) tcx/egress tcx_egress_flow_parse prog_id 3922 link_id 213 >br-68b237cee3d3(3) tcx/ingress tcx_ingress_flow_parse prog_id 3923 link_id 216 >br-68b237cee3d3(3) tcx/egress tcx_egress_flow_parse prog_id 3922 link_id 215 >docker0(4) tcx/ingress tcx_ingress_flow_parse prog_id 3923 link_id 218 >docker0(4) tcx/egress tcx_egress_flow_parse prog_id 3922 link_id 217 >enp9s0u2u1u2(1736) tcx/ingress tcx_ingress_flow_parse prog_id 3923 link_id 220 >enp9s0u2u1u2(1736) tcx/egress tcx_egress_flow_parse prog_id 3922 link_id 219 > >flow_dissector: > >netfilter: > >``` >- testing >* [X] using `6.6.2-201.fc39.x86_64` run standalone agent code as well as e2e test and both passed with the new TCX. Waiting for OCP build with rhel9.4 to be able to resume the testing on OCP cluster > >* [ ] pkt drop >* [ ] DNS >* [ ] RTT >* [ ] SRIOV secondary interface >* [ ] PCA >* [ ] performance and scale test > >* [X] on older kernel we will get this warning and fall back to the legacy TC hooks >```sh >time="2024-02-05T12:56:55Z" level=info msg="interface detected. trying to attach TCX hook" component=agent.Flows interface="{1b684d9681b6cb8 106 NS(none)}" >time="2024-02-05T12:56:55Z" level=warning msg="can't attach to TCx hook flow ebpfFetcher. fall back to use legacy TC hook" component=agent.Flows error="failed to attach TCX egress: tcx not supported (requires >= v6.6)" interface="{1b684d9681b6cb8 106 NS(none)}" >``` >Note: GH use `ubuntu-latest` which is currently `6.2.0` so doesn't have TCX support yet >## Dependencies > >OCP with rhel9.4 kernel > >## Checklist > >If you are not familiar with our processes or don't know what to answer in the list below, let us know in a comment: the maintainers will take care of that. > >* [ ] Will this change affect NetObserv / Network Observability operator? If not, you can ignore the rest of this checklist. >* [X] Is this PR backed with a JIRA ticket? If so, make sure it is written as a title prefix _(in general, PRs affecting the NetObserv/Network Observability product should be backed with a JIRA ticket - especially if they bring user facing changes)._ >* [X] Does this PR require product documentation? > * [ ] If so, make sure the JIRA epic is labelled with "documentation" and provides a description relevant for doc writers, such as use cases or scenarios. Any required step to activate or configure the feature should be documented there, such as new CRD knobs. >* [ ] Does this PR require a product release notes entry? > * [ ] If so, fill in "Release Note Text" in the JIRA. >* [ ] Is there anything else the QE team should know before testing? E.g: configuration changes, environment setup, etc. > * [ ] If so, make sure it is described in the JIRA ticket. >* QE requirements (check 1 from the list): > * [X] Standard QE validation, with pre-merge tests unless stated otherwise. > * [ ] Regression tests only (e.g. refactoring with no user-facing change). > * [ ] No QE (e.g. trivial change with high reviewer's confidence, or per agreement with the QE team). > Instructions for interacting with me using PR comments are available [here](https://prow.ci.openshift.org/command-help?repo=netobserv%2Fnetobserv-ebpf-agent). If you have questions or suggestions related to my behavior, please file an issue against the [openshift-eng/jira-lifecycle-plugin](https://github.com/openshift-eng/jira-lifecycle-plugin/issues/new) repository.
msherif1234 commented 7 months ago

/ok-to-test

msherif1234 commented 7 months ago

/ok-to-test

github-actions[bot] commented 7 months ago

New image: quay.io/netobserv/netobserv-ebpf-agent:f437213

It will expire after two weeks.

To deploy this build, run from the operator repo, assuming the operator is running:

USER=netobserv VERSION=f437213 make set-agent-image
msherif1234 commented 7 months ago

/ok-to-test

github-actions[bot] commented 7 months ago

New image: quay.io/netobserv/netobserv-ebpf-agent:219d7c0

It will expire after two weeks.

To deploy this build, run from the operator repo, assuming the operator is running:

USER=netobserv VERSION=219d7c0 make set-agent-image
msherif1234 commented 6 months ago

/ok-to-test

github-actions[bot] commented 6 months ago

New image: quay.io/netobserv/netobserv-ebpf-agent:237fd0e

It will expire after two weeks.

To deploy this build, run from the operator repo, assuming the operator is running:

USER=netobserv VERSION=237fd0e make set-agent-image
msherif1234 commented 6 months ago

/ok-to-test

codecov-commenter commented 6 months ago

Codecov Report

Attention: Patch coverage is 2.18978% with 134 lines in your changes are missing coverage. Please review.

Project coverage is 33.41%. Comparing base (cb2cf53) to head (b5f42f2). Report is 9 commits behind head on main.

Files Patch % Lines
pkg/ebpf/tracer.go 0.00% 113 Missing :warning:
pkg/ebpf/bpf_x86_bpfel.go 0.00% 8 Missing :warning:
pkg/agent/packets_agent.go 0.00% 7 Missing :warning:
pkg/agent/agent.go 14.28% 5 Missing and 1 partial :warning:
Additional details and impacted files ```diff @@ Coverage Diff @@ ## main #262 +/- ## ========================================== - Coverage 33.63% 33.41% -0.22% ========================================== Files 47 48 +1 Lines 3865 3477 -388 ========================================== - Hits 1300 1162 -138 + Misses 2477 2218 -259 - Partials 88 97 +9 ``` | [Flag](https://app.codecov.io/gh/netobserv/netobserv-ebpf-agent/pull/262/flags?src=pr&el=flags&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=netobserv) | Coverage Δ | | |---|---|---| | [unittests](https://app.codecov.io/gh/netobserv/netobserv-ebpf-agent/pull/262/flags?src=pr&el=flag&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=netobserv) | `33.41% <2.18%> (-0.22%)` | :arrow_down: | Flags with carried forward coverage won't be shown. [Click here](https://docs.codecov.io/docs/carryforward-flags?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=netobserv#carryforward-flags-in-the-pull-request-comment) to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

github-actions[bot] commented 6 months ago

New image: quay.io/netobserv/netobserv-ebpf-agent:38dbfc2

It will expire after two weeks.

To deploy this build, run from the operator repo, assuming the operator is running:

USER=netobserv VERSION=38dbfc2 make set-agent-image
msherif1234 commented 6 months ago

verified with https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=59954477

msherif1234 commented 6 months ago

/ok-to-test

github-actions[bot] commented 6 months ago

New image: quay.io/netobserv/netobserv-ebpf-agent:6df65c5

It will expire after two weeks.

To deploy this build, run from the operator repo, assuming the operator is running:

USER=netobserv VERSION=6df65c5 make set-agent-image
msherif1234 commented 6 months ago

Code looks good; any tips to test this on a cluster ?

yes detailed instructions on how to test this on OCP is in the comment section for https://issues.redhat.com/browse/NETOBSERV-1473

msherif1234 commented 5 months ago

/ok-to-test

github-actions[bot] commented 5 months ago

New image: quay.io/netobserv/netobserv-ebpf-agent:a8f1bf4

It will expire after two weeks.

To deploy this build, run from the operator repo, assuming the operator is running:

USER=netobserv VERSION=a8f1bf4 make set-agent-image
msherif1234 commented 5 months ago

/ok-to-test

msherif1234 commented 5 months ago

did multiple rebase to keep with latest code, no functional changes

github-actions[bot] commented 5 months ago

New image: quay.io/netobserv/netobserv-ebpf-agent:8ce8080

It will expire after two weeks.

To deploy this build, run from the operator repo, assuming the operator is running:

USER=netobserv VERSION=8ce8080 make set-agent-image
msherif1234 commented 5 months ago

/ok-to-test

github-actions[bot] commented 5 months ago

New image: quay.io/netobserv/netobserv-ebpf-agent:bc5abad

It will expire after two weeks.

To deploy this build, run from the operator repo, assuming the operator is running:

USER=netobserv VERSION=bc5abad make set-agent-image
msherif1234 commented 5 months ago

/approve

msherif1234 commented 5 months ago

discussed with @Amoghrd and he is fine running QE verification post merge

openshift-ci[bot] commented 5 months ago

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: msherif1234

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files: - ~~[OWNERS](https://github.com/netobserv/netobserv-ebpf-agent/blob/main/OWNERS)~~ [msherif1234] Approvers can indicate their approval by writing `/approve` in a comment Approvers can cancel approval by writing `/approve cancel` in a comment