On 21 Nov 2024, at 6:56, Rama Chaitanya Kandula wrote:
> 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. Don’t think we can control them separately as is. By default, when you enable hardware offload for the kernel/netlink dpif, you will switch from the kernel module to TC rules where possible. So the ingress qdisc handles are needed. I think the reason why OVS adds them is to be sure they are set up in such a way they work for OVS, but I’m not an expert in this area. > 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
