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. 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
