Thanks for the response. Can you please help with below question. Does the sole purpose of having hw-offload flag set to true is enabling TC QDISC attachment on all interfaces ? In case if we want to control only this feature such that OVS does not create any QDISC but some additional software creates will Hardware offload work the same. The reason to ask this query is mainly because, we are observing that both egress and ingress QDISC handles are not being stored in any data structures in OVS, they created using Netlink and default programming of TC rules is ensuring traffic is steered. We wanted to propose an approach whether only this action can be controlled separately.
Thanks Rama From: Eelco Chaudron <echau...@redhat.com> Date: Monday, 18 November 2024 at 3:31 PM To: Rama Chaitanya Kandula <ramachaitany...@nutanix.com> Cc: ovs-discuss@openvswitch.org <ovs-discuss@openvswitch.org>, Rama Shankar Pandey <rama.pan...@nutanix.com> Subject: Re: [ovs-discuss] Understanding TC qdisc behaviour with hw-offload flag set as TRUE !-------------------------------------------------------------------| CAUTION: External Email |-------------------------------------------------------------------! On 16 Nov 2024, at 8:05, Rama Chaitanya Kandula via discuss wrote: > Hi Team members, > > We are trying to experiment the TC qdisc behaviour with hw-offload > enabled(Kernel offload using TC). Need clarification on below queries. > > > 1. As part of HW Offload being enabled on OVS (using ovs-vsctl set > Open_vSwitch . other_config:hw-offload=true), we are observing that the TC > INGRESS QDISC is always getting created by OVS on addition of tap to bridge. > Please can you help us in understanding why this is being added to all the > ports which are participating in the bridge ? Our understanding is that > virtual port like tap won’t be participate in HW offload. When hardware offload for the kernel is enabled by default all port (even the non-hardware offload capable ones) will use TC for datapath handling. If a flow is not supported by TC it will fall back to the kernel module. > 2. We also wanted to understand the reason behind keeping the TC INGRESS > QDISC creation as Exclusive flag. We are trying to supplement this with > another qdisc (tc qdisc add dev tap0 clsact) but the creation itself is > failing since the current INGRESS qdisc is kept with Exclusivity flag turned > on. Not sure why we chose to set this flag. I assume to avoid people from tampering with the OVS applied configuration. > > Thanks in advance, > Rama Chaitanya > _______________________________________________ > discuss mailing list > disc...@openvswitch.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.openvswitch.org_mailman_listinfo_ovs-2Ddiscuss&d=DwIFaQ&c=s883GpUCOChKOHiocYtGcg&r=sbX53YJlKD0QNHNAai1nHo6pw5ljGYig4MhlSUycgdI&m=DTXrT_HOTj62H_GUAOo6FqXFz5QY6k2zw33OzngVJlnYfSALiMuSls-L9a2wu78i&s=67-l8nyIOdqbp9nNtz1fAXu94KfB7I4c4Dg1lwiLcQg&e=
_______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
