On Tue, Aug 10, 2021 at 12:22 PM Vladislav Odintsov <[email protected]> wrote: > > Thanks Numan for your help! > > I’ve sent patch, which fixes documentation: > https://patchwork.ozlabs.org/project/ovn/patch/[email protected]/ > > Since lr_in_defrag stage first writes xxreg0 register only in master branch > after > https://github.com/ovn-org/ovn/commit/fb6de664f061c51040a4aae39049aa3cd4a0b1fa > and prior this commit it was lr_in_ip_routing for a long time, should I make > a separate > backport patch to branch-21.06 in which lr_in_defrag replaced with > lr_in_ip_routing > for futher backport down to branch-20.06? > I think it’s reasonable to have actual documentation in old branches too.
Thanks. I'll take a look at the patch. I think you can submit backport patches once the main patch is applied to the main branch. Numan > > Regards, > Vladislav Odintsov > > > On 10 Aug 2021, at 18:28, Numan Siddique <[email protected]> wrote: > > > > On Tue, Aug 10, 2021 at 8:00 AM Vladislav Odintsov <[email protected] > > <mailto:[email protected]>> wrote: > >> > >> Hi Numan, > >> > >> thanks for the answer. > >> > >> You said that it’s possible to use reg2-reg7 for ipv4. > >> I’ve checked usage of xxreg0 and xxreg1 to find out where they’re used in > >> router pipeline. > >> > >> In ovn-northd.c it’s written that those ipv6-related registers are used in > >> >= IP_INPUT. Am I right, its about lrouter stage "lr_in_ip_input"? > > > > That's correct. > > > >> If yes, I’ve analyzed ovn-northd code and it looks like first time when > >> xxreg0 is used to write is lr_in_defrag. > > > > I think you're referring to this code right > > https://github.com/ovn-org/ovn/blob/master/northd/ovn-northd.c#L9288 > > <https://github.com/ovn-org/ovn/blob/master/northd/ovn-northd.c#L9288> ? > > > > If so, yes you'r right and we should definitely update the documentation. > > Yes, I looked at this place. > > > > > And xxreg1 is used in write mode first time in lr_in_ip_routing. > >> > >> Can you please cofirm I am right, that I can use xxreg1’s subregisters > >> (for instance, reg7) in one stage prior to lr_in_ip_routing? > > > > I think you can use xxxreg1's sub registers prior to > > lr_in_ip_routing. If you do this, then the usage can be for both IPv4 > > and IPv6. > > > > If you want to write xxreg1's sub registers after ip_routing, then > > your feature would be restricted to just IPv4. > > > > > >> If yes, I think we should fix router’s registers usage documentation: > >> xxreg0: ">= IP_INPUT" -> ">= DEFRAG" > >> xxreg1: ">= IP_INPUT" -> ">= IP_ROUTING" > > > > Agree. > > > > Thanks > > Numan > > > > > >> > >> Right? > >> > >> Regards, > >> Vladislav Odintsov > >> > >>> On 9 Aug 2021, at 00:09, Numan Siddique <[email protected] > >>> <mailto:[email protected]>> wrote: > >>> > >>> On Thu, Aug 5, 2021 at 1:29 PM Vladislav Odintsov <[email protected] > >>> <mailto:[email protected]> <mailto:[email protected] > >>> <mailto:[email protected]>>> wrote: > >>>> > >>>> Hi, > >>>> > >>>> I’m trying to implement multiple routing tables support for Logical > >>>> Routers and met some difficulties, need help/advice. > >>>> > >>>> How I see it can be used by administrators: > >>>> > >>>> 1. In LRP’s options field is added key route_table with the routing > >>>> table’s name - any string. > >>>> 2. When adding new logical router static route record, supply optional > >>>> parameter - route_table. > >>>> 3. If route_table values in LRP and LR route match, packets coming from > >>>> this particular LRP are looked up against routes with mentioned > >>>> route_table value. > >>>> 4. Routes to directly-connected networks of LRs have higher priority > >>>> that routes from route_tables. > >>>> > >>>> So, this functionality can help achieve different routes loockup for > >>>> different LR’s subnets. > >>>> > >>>> Planned changes: > >>>> - add route_table field to Logical_Router_Static_Route table’s schema > >>>> - add new optional field to Logical_Router_Static_Routes table, which > >>>> when absent indicates that route is global for LR (current behaviour), > >>>> and when there is a string with route_table name > >>>> > >>>> Regards, > >>>> Vladislav Odintsov > >>>> - add new stage in logical router ingress pipeline right before > >>>> lr_in_ip_routing - lr_in_ip_routing_pre. In this stage packets are > >>>> checked against inport and route_table’s id (computed somehow, uniq per > >>>> route_table of LR) writes to some of OVS registers and then passes to > >>>> next table - lr_in_ip_routing. Currently in my dev env it looks like > >>>> this: > >>>> > >>>> table=9 (lr_in_ip_routing_pre), priority=100 , match=(inport == > >>>> "subnet-8E3CDCC0"), action=(reg7 = 110; next;) > >>>> table=9 (lr_in_ip_routing_pre), priority=100 , match=(inport == > >>>> "subnet-E99CDA60"), action=(reg7 = 100; next;) > >>>> table=9 (lr_in_ip_routing_pre), priority=0 , match=(1), action=(next;) > >>>> > >>>> - routes, which have route_table set, are added to lflow with match on > >>>> previously set value of computed uniq route_table id, stored in OVS > >>>> register. Like this: > >>>> > >>>> table=10(lr_in_ip_routing ), priority=1 , match=(reg7 == 100 && > >>>> ip4.dst == 0.0.0.0/0), action=(ip.ttl--; reg8[0..15] = 0; reg0 = > >>>> 169.254.0.1; reg1 = 169.254.0.2; eth.src = 06:00:b1:5f:12:77; outport = > >>>> "vpc-B15F1277-up"; flags.loopback = 1; next;) > >>>> table=10(lr_in_ip_routing ), priority=1 , match=(reg7 == 110 && > >>>> ip4.dst == 0.0.0.0/0), action=(ip.ttl--; reg8[0..15] = 0; reg0 = > >>>> 169.254.0.1; reg1 = 169.254.0.2; eth.src = 06:00:b1:5f:12:77; outport = > >>>> "vpc-B15F1277-up"; flags.loopback = 1; next;) > >>>> > >>>> > >>>> My question is about OVS register choice. > >>>> > >>> > >>>> I see in ovn-northd.c described OVS fields and (please correct me, if > >>>> I’m wrong) it looks like there are no registers available to store > >>>> route_table id? It looks for me that all registers are busy. What should > >>>> I do in this particular situation? If I set reg10, for instance, > >>>> ovn-controller can’t process such match and action, thus it’s an unknown > >>>> symbol. If I increase the MFF_N_LOG_REGS from 10 to 12, ovn connectivity > >>>> tests fail and even arp/ip connectivity drops. (see commit: > >>>> https://github.com/ovn-org/ovn/commit/18e71b5240009c519dc44eb06d101b3edd9dc103 > >>>> > >>>> <https://github.com/ovn-org/ovn/commit/18e71b5240009c519dc44eb06d101b3edd9dc103> > >>>> > >>>> <https://github.com/ovn-org/ovn/commit/18e71b5240009c519dc44eb06d101b3edd9dc103 > >>>> > >>>> <https://github.com/ovn-org/ovn/commit/18e71b5240009c519dc44eb06d101b3edd9dc103>> > >>>> > >>>> <https://github.com/ovn-org/ovn/commit/18e71b5240009c519dc44eb06d101b3edd9dc103 > >>>> > >>>> <https://github.com/ovn-org/ovn/commit/18e71b5240009c519dc44eb06d101b3edd9dc103> > >>>> > >>>> <https://github.com/ovn-org/ovn/commit/18e71b5240009c519dc44eb06d101b3edd9dc103 > >>>> > >>>> <https://github.com/ovn-org/ovn/commit/18e71b5240009c519dc44eb06d101b3edd9dc103>>>) > >>>> > >>>> I’m new to OVN development, please help :) > >>>> Thanks in advance! > >>> > >>> From your email, I'm not clear about the new feature you're planning > >>> to add. But since your question is about registers, I guess I can > >>> answer your question. > >>> > >>> Registers R0 - R9 are used by ovn-northd and regsiters R10 - 15 are > >>> used by ovn-controller - > >>> https://github.com/ovn-org/ovn/blob/master/include/ovn/logical-fields.h#L34 > >>> > >>> <https://github.com/ovn-org/ovn/blob/master/include/ovn/logical-fields.h#L34> > >>> > >>> <https://github.com/ovn-org/ovn/blob/master/include/ovn/logical-fields.h#L34 > >>> > >>> <https://github.com/ovn-org/ovn/blob/master/include/ovn/logical-fields.h#L34>> > >>> The reason why the tests failed when your increared the MFF_N_LOG_REGS > >>> to 12 is because R10 is used by ovn-controller. > >>> > >>> One possible solution I see is to use any register from R2 to R7 to > >>> store route table id. But this would restrict the router table ids > >>> only for IPv4 traffic. > >>> > >>> Looks to me we have run out of OVS registers in the router pipeline. > >>> > >>> Thanks > >>> Numan > >>> > >>>> > >>>> > >>>> Regards, > >>>> Vladislav Odintsov > >>>> > >>>> _______________________________________________ > >>>> dev mailing list > >>>> [email protected] <mailto:[email protected]> > >>>> <mailto:[email protected] <mailto:[email protected]>> > >>>> https://mail.openvswitch.org/mailman/listinfo/ovs-dev > >>>> <https://mail.openvswitch.org/mailman/listinfo/ovs-dev> > >>>> <https://mail.openvswitch.org/mailman/listinfo/ovs-dev > >>>> <https://mail.openvswitch.org/mailman/listinfo/ovs-dev>> > >> _______________________________________________ > >> dev mailing list > >> [email protected] <mailto:[email protected]> > >> https://mail.openvswitch.org/mailman/listinfo/ovs-dev > >> <https://mail.openvswitch.org/mailman/listinfo/ovs-dev> > > _______________________________________________ > > dev mailing list > > [email protected] <mailto:[email protected]> > > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > > <https://mail.openvswitch.org/mailman/listinfo/ovs-dev> > _______________________________________________ > dev mailing list > [email protected] > https://mail.openvswitch.org/mailman/listinfo/ovs-dev _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
