On 10/3/25 2:25 PM, Ilya Maximets wrote: > On 10/3/25 11:01 AM, Dumitru Ceara wrote: >> I think it might make sense to have a dedicated (set of) registers >> that are preserved between logical pipelines. The problem is we >> currently are out of OVS registers that we can use: >> >> /* Logical fields. >> * >> * These values are documented in ovn-architecture(7), please update the >> * documentation if you change any of them. */ >> #define MFF_LOG_DATAPATH MFF_METADATA /* Logical datapath (64 bits). */ >> #define MFF_LOG_FLAGS MFF_REG10 /* One of MLF_* (32 bits). */ >> #define MFF_LOG_DNAT_ZONE MFF_REG11 /* conntrack dnat zone for gateway >> router >> * (32 bits). */ >> #define MFF_LOG_SNAT_ZONE MFF_REG12 /* conntrack snat zone for gateway >> router >> * (32 bits). */ >> #define MFF_LOG_CT_ZONE MFF_REG13 /* Logical conntrack zone for lports >> * (0..15 of the 32 bits). */ >> #define MFF_LOG_ENCAP_ID MFF_REG13 /* Encap ID for lports >> * (16..31 of the 32 bits). */ >> #define MFF_LOG_INPORT MFF_REG14 /* Logical input port (32 bits). */ >> #define MFF_LOG_OUTPORT MFF_REG15 /* Logical output port (32 bits). */ >> >> I had a quick glance at OVS' code and I _think_ there should be no >> major issue if we add a nother xxreg (i.e., 2 extra xregs / 4 extra regs). >> >> We're also running low on available bits in the logical flags register >> (that's also preserved between ingress and egress) so having some extra >> register storage space to work with would make our lives easier. The >> impact of adding new registers should be relatively minimal (I guess) as >> it would only potentially increase the upcall handling time but likely >> with a marginal amount. >> >> I'm CC-ing Ilya to see if such a change would be acceptable in OVS. > > It should be fine to increase the register space in OVS. A bigger hurdle > will be for OVN to turn on and off features based on register availability, > but that should also be doable. > > In the past OVS increased the space by doing x2 of the previous one. May > need to check if that's based on some requirements or not. It may also be > good to add extra space for future extensions to avoid adding new registers > frequently, if it doesn't have a big performance impact, of course. > The main performance concern is that adding more registers will inflate the > size of the struct flow. But it is already 672 bytes in size. Adding 64 > more bytes should hopefully not be a huge problem. >
Thanks, Ilya, for the feedback! I'll have a closer look at a potential implementation on the ovn-controller side. Regards, Dumitru _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
