On 12/17/25 5:47 PM, Numan Siddique wrote: > On Wed, Dec 17, 2025 at 11:01 AM Eelco Chaudron <[email protected]> wrote: >> >> >> >> On 29 Nov 2025, at 0:08, [email protected] wrote: >> >>> From: Numan Siddique <[email protected]> >>> >>> netdev-offload-tc when offloading a flow to tc, uses the flow's >>> recirc_id as flower chain id. recirc_id is of type 'uint32_t'. >>> Kernel tc reserves the upper nibble (4 bits) of the tc flower's >>> chain index for extended action opcode [1]. If a flow's recirc_id >>> value is greater than 268,435,455 (0x0fffffff), kernel returns >>> EINVAL when ovs-vswitchd tries to offload the flow. >>> >>> This commit fixes this offload issue by setting the maximum >>> value of recirc id to 268,435,455 when hw-offload is enabled. >>> >>> Note: This commit renames a static function - mirror_destroy() >>> to mirror_delete() in vswitchd/bridge.c since a public function >>> with the same name exists in ofproto/ofproto-dpif-mirror.c. >> >> Hi Numan, >> >> Rather than adding all this infrastructure, should we maybe limit the >> recirc_id to 2^28 - 1? > > I don't have a strong opinion. Just that userspace datapaths will be > limited as well. > > Based on the comments from Ilya and others, please let me know which > way you prefer and I'll update the patch accordingly. > > >> >> Others WDYT? Anyhow, some comments below.
Yeah, I guess, all this infra is a bit excessive. So, it might make sense to just limit the id space in general. 2**28 is a fairly big number and we should not have that many datapath flows or other states that require recirculation id allocation. For example, the datapath flow limit by default is just 200K. So, it should be fine to limit. Just add a comment on why this number is chosen. nit: in the subject line it probably should be ^ or **, not ^^. Best regards, Ilya Maximets. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
