Hi Raja,
Thanks a lot for taking out time to review the blueprint/spec. I am ok with your suggested approach. However just to explain the reasoning behind the approach of showing member links in "vif --list" I am providing few points below. Please go through these once and then if you still feel we should not display slave in "vif--list" then I will change the spec accordingly. Secondly, I would like this change to be part of ongoing r4.1 of Opencontrail. Can you please let me know what is the deadline till which the changes are being accepted for r4.1. Is there some place where I can find the Opencontrail release schedule, in terms of cut-off dates for design, code commits etc. ? Review comments ========================== Comment:1 “Line 38: 0 Would prefer to not display this in "vif --list" output. The unique identifier of a member of a bond interface is its PCI id. We can add an option to vifdump (say "-p") that specifies this PCI id. So, the command would be something like "vifdump -i 0 -p 0004:00:00", where 0 is the vif index of the bond. vifdump can send this PCI id encoded as an integer using the "--pmd" option to "vif" command. This will allow vrouter to identify which member link to monitor (by searching for its PCI id in the list of devices). “ 1. Although the user who created the bond-interface and added slaves to it knows the PCI-id of slave interfaces however once we have VRouter-DPDK running, if some other user needs to use vifdump utility then he may find it difficult to find those PCI-ids of member links because he will not be able to see it via either "ifconfig", "vif--list" or "lspci". Showing slaves/members in "vif --list" will be handy for a end-user 2. Comparing it with "ifconfig" and "tcpdump" for kernel interfaces, the bond as well as its members are visible as output of "ifconfig" command. So if we display slaves in "vif --list" output then it is aligned to "ifconfig" behaviour as well 3. In case, you are apprehensive that the approach to show slaves in "vif --list" would be more complex and would require more code changes, then I would like to assure you that this is not the case. I have briefly explained the approach below. In fact the code changes have already been done and I would request you to please have a look Code-changes: https://github.com/deepak-dt/contrail-vrouter/commit/38db2603e09f91a71571633d823b8bb47ace1755 1. Show slave interfaces with their display name codifying the physical eth port, i.e. vif0/1/slave2 (where, 1 is bond vif-id while 2 is eth-port of slave interface) 2. User will use this name "vif0/1/slave2" to start monitoring for the slave, i.e. - vifdump -i vif0/1/slave2 [tcpdump_arguments] 3. vifdump will send following command to vif :- - sudo vif --add mon1/slave2 --type monitoring --vif 1 --id 4351 >/dev/null 4. vif will send "vif_name" as "mon1/slave2" to vrouter 5. Based on the substring "slave" in "vif_name", vrouter (vr_dpdk_interface.c) will get the slave's eth-port from it. Comment:2 “We might need some change in vifdump to allow monitoring of multiple members of a bond simultaneously (see generation of MON_VIF_ID).” In current implementation ‘vifdump’ generates the MON_VIF_ID in following way— - Initialize MON_VIF_ID from the other side of interface-id range, i.e. MON_VIF_ID=$((${VR_MAX_INTERFACES} - ${MON_IF_ID} - 1)) Where, a. #define VR_MAX_INTERFACES (256 + 4096) b. MON_IF_ID = VIF_ID of monitored interface; if slave is being monitored this will have VIF_ID of bond - From this starting value of MON_VIF_ID, it then keeps on traversing in reverse direction (subtracting 1 each time) until it finds a free VIF_ID In my view, this existing approach should work even in our case as well? For ex. if [Mon_vif_id=X] is being used for slave-1 then for slave-2 it will select [mon_vif_id=X-1] ? Is my understanding correct or am I missing something here? Br, Deepak From: Rajagopalan Sivaramakrishnan [mailto:r...@juniper.net] Sent: 11 April 2017 07:13 To: Deepak Tiwari <deepak.tiw...@aricent.com>; dev@lists.opencontrail.org Subject: Re: [opencontrail-dev] Contrailen 171 - vrouter vifdump mirroring enhancement for bond-slave-links Hi Deepak, I have updated the review with comments. Please take a look and we can discuss further if required. Raja From: Deepak Tiwari <deepak.tiw...@aricent.com<mailto:deepak.tiw...@aricent.com>> Date: Sunday, April 9, 2017 at 11:26 PM To: Rajagopalan Sivaramakrishnan <r...@juniper.net<mailto:r...@juniper.net>>, "dev@lists.opencontrail.org<mailto:dev@lists.opencontrail.org>" <dev@lists.opencontrail.org<mailto:dev@lists.opencontrail.org>> Subject: RE: [opencontrail-dev] Contrailen 171 - vrouter vifdump mirroring enhancement for bond-slave-links Hi Raja, Were you able to review the blueprint and specs last week. Please share the comments, we’ll incorporate those and float the updated version Br, Deepak From: Rajagopalan Sivaramakrishnan [mailto:r...@juniper.net] Sent: 06 April 2017 11:08 To: Deepak Tiwari <deepak.tiw...@aricent.com<mailto:deepak.tiw...@aricent.com>>; dev@lists.opencontrail.org<mailto:dev@lists.opencontrail.org> Subject: Re: [opencontrail-dev] Contrailen 171 - vrouter vifdump mirroring enhancement for bond-slave-links Hi Deepak, Thank you for the blueprint. It is a good proposal. I have some comments and will post them on the review this week. Raja From: Dev <dev-boun...@lists.opencontrail.org<mailto:dev-boun...@lists.opencontrail.org>> on behalf of Deepak Tiwari <deepak.tiw...@aricent.com<mailto:deepak.tiw...@aricent.com>> Date: Tuesday, April 4, 2017 at 1:08 AM To: "dev@lists.opencontrail.org<mailto:dev@lists.opencontrail.org>" <dev@lists.opencontrail.org<mailto:dev@lists.opencontrail.org>> Subject: [opencontrail-dev] Contrailen 171 - vrouter vifdump mirroring enhancement for bond-slave-links Hello All, We have submitted a blueprint to enhance the ‘vifdump’ utility to be able to also capture the slave interfaces of a bond interface. Following are the spec details for the problem we are attempting to solve and the proposed solution. Please review the same and provide your valuable feedback Problem statement: The Kernel level tools, like tcpdump, do not work when vRouter is deployed in DPDK mode, since the Linux network stack is bypassed. There exist already a tcpdump like command (i.e. vifdump), which works on the bond interface but it can’t be used to monitor its slave/member interfaces; so there is no way to debug each slave individually.” Launchpad Blueprint: https://blueprints.launchpad.net/opencontrail/+spec/contrailen-171-vrouter-vifdump-mirroring-for-bond-slaves Bug #1679466: Tracking vRouter changes for Contrailen 171 - vrouter vifdump mirroring enhancement for bond-slave-links https://bugs.launchpad.net/opencontrail/+bug/1679466 Spec: https://review.opencontrail.org/30107 Br, Deepak "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus." "DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."
_______________________________________________ Dev mailing list Dev@lists.opencontrail.org http://lists.opencontrail.org/mailman/listinfo/dev_lists.opencontrail.org
