By a tag, you mean an element like @todo that both renders the paragraph such that it stands out and also produces a list (index) of all such items? That is fairly straightforward.
There is some limited functionality for this built in to Doxygen[1], and separately I wrote a pre-Doxygen-parser that does similar for CLI commands[2]. Either mechanism would work for this. The former requires less glue maintenance, the latter gives us more formatting control. [1] An example of this is https://docs.fd.io/vpp/17.04/nodes.html which we use to index all the nodes, though in that case we only use it as a reference for the node name. Key detractor for this method is that it’s indexing them against the source code and not, eg, the CLI or API call. [2] https://docs.fd.io/vpp/17.04/clicmd.html Is the index page. It links to text on each CLI command which in turn then links to the source code reference. All of the parts are built from jinja templates. I think with some small amount of work, detecting a special @constraint or @limitation or some such tag inside the CLI documentation and adding an index for that should be doable, and generalizable (so we can add others later). Chris. From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Dave Wallace Sent: Tuesday, January 17, 2017 11:10 AM To: Billy McFall <bmcf...@redhat.com> Cc: vpp-dev@lists.fd.io Subject: Re: [vpp-dev] show interface address with multiple tables Billy, Thanks for pointing out that this particular case is documented in doxygen. I didn't follow up on this specific example but was highlighting the general issue. It would be nice to have specific tag in Doxygen which identifies configuration constraint definitions. Thanks, -daw- On 1/17/17 10:13 AM, Billy McFall wrote: Dave, I agree with your statements about VPP probably needs to add the verification. I wanted to add that this constraint was added to the Doxygen documentation. But there are a lot of constraints that are not documented, and if they are, I'm not sure how to better propagate the information to masses. From the Doxygen documentation for "set interface ip table": Note IP addresses added after setting the interface IP table end up in the indicated FIB table. If the IP address is added prior to adding the interface to the FIB table, it will NOT be part of the FIB table. Predictable but potentially counter-intuitive results occur if you provision interface addresses in multiple FIBs. Upon RX, packets will be processed in the last IP table ID provisioned. It might be marginally useful to evade source RPF drops to put an interface address into multiple FIBs. Billy McFall On Tue, Jan 17, 2017 at 9:45 AM, Dave Wallace <dwallac...@gmail.com<mailto:dwallac...@gmail.com>> wrote: Neale, Given this constraint, IMO it should be verified prior to enacting the change of the interface table and the request should be rejected if the constraint is not met. The $64,000 question is whether this constraint should be verified by VPP itself or the management agent. Prior to open sourcing VPP, when there was a dedicated management agent, Dave and I agreed that constraint verification was the responsibility of the management agent. Now that VPP is open source and there are potentially numerous management agents, it seems to me that including configuration constraint verification in the VPP might make more sense as a defensive mechanism. In either case, there is a general lack of documentation on feature constraints that needs to be addressed. In the past, I have worked on a system where the entire set of system configuration constraints was documented in the bug tracking system. Needless to say, this was a less than optimal means of communicating the set of requirements. Thanks, -daw- On 1/17/2017 2:20 AM, Neale Ranns (nranns) wrote: Hi Choonho, An interface can only reside in (a.k.a be bound to) a single table. So each time you do; Set int ip table loop0 X You are changing the table it is bound to, not adding tables. So the output you see at the end of the sequence is correct, the loopback has two addresses and is bound to table 5. However, this is not a supported sequence of events. You MUST remove all configured IP address on an interface before you change the interface’s table. Regards, neale From: <vpp-dev-boun...@lists.fd.io><mailto:vpp-dev-boun...@lists.fd.io> on behalf of Choonho Son <choonho....@gmail.com><mailto:choonho....@gmail.com> Date: Tuesday, 17 January 2017 at 00:17 To: "vpp-dev@lists.fd.io"<mailto:vpp-dev@lists.fd.io> <vpp-dev@lists.fd.io><mailto:vpp-dev@lists.fd.io> Subject: [vpp-dev] show interface address with multiple tables With multiple tables(VRF), show interface addr display wrong table ID. DBGvpp# create loopback interface loop0 DBGvpp# set interface ip table loop0 1 DBGvpp# set interface ip address loop0 1.0.0.250/16<http://1.0.0.250/16> DBGvpp# sh int addr local0 (dn): loop0 (dn): 1.0.0.250/16<http://1.0.0.250/16> table 1 DBGvpp# set interface ip table loop0 5 DBGvpp# set interface ip address loop0 5.0.0.250/16<http://5.0.0.250/16> DBGvpp# sh int addr local0 (dn): loop0 (dn): 1.0.0.250/16<http://1.0.0.250/16> table 5 5.0.0.250/16<http://5.0.0.250/16> table 5 DBGvpp# The reason looks like ip4_main_t has single fib_index_by_sw_if_index. Even though sw_if_index has two table ID(fib_index) 1 and 5. Last updated fib_index(Table 5) is updated at ip4_main_t. _______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> https://lists.fd.io/mailman/listinfo/vpp-dev _______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> https://lists.fd.io/mailman/listinfo/vpp-dev
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
