Hi Ben, In addition to my previous response, please suggest if "vswitchd" should query and get the current stored table-configurartion using query_tables_desc() and then modify table-config properties according to user's request.
Thanks and Regards, Saloni Jain Tata Consultancy Services Mailto: saloni.j...@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ -----"dev" <dev-boun...@openvswitch.org> wrote: ----- To: Ben Pfaff <b...@nicira.com> From: Saloni Jain Sent by: "dev" Date: 07/14/2015 11:40AM Cc: dev@openvswitch.org, Deepankar Gupta <deepankar.gu...@tcs.com>, Partha Datta <partha.da...@tcs.com> Subject: Re: [ovs-dev] ovs-ofctl mod-table commands supporting OF1.4 Eviction and Vacancy-Events Hi Ben, Thanks for the reply. Please help me understand below points: As per openflow specification 1.4, Page 72 "The flag OFPTC_VACANCY_EVENTS control vacancy events in that table (see 7.4.5). If this flag is set, the switch must generate vacancy events for that table. If this flag is unset, the switch must not generate those events. Parameters for vacancy events may be specified using the OFPTMPT_VACANCY property." This means that OFPTC_VACANCY_EVENTS is property for the table and not for per-OpenFlow connection basis. Regarding the events, then only those controller will get vacancy events which have OFPT_TABLE_STATUS messages set on using "set-async configuration" OFPT_SET_ASYNC. Page 121 of openflow 1.4 says that "The OFPT_SET_ASYNC message sets whether a controller should receive a given asynchronous message that is generated by the switch. Other OpenFlow features control whether a given message is generated; for example, the OFPFF_SEND_FLOW_REM flag in each flow entry controls whether the switch generates a OFPT_FLOW_REMOVED message when a flow entry is removed. The asynchronous configuration acts as an additional per-controller filter; for example it defines if a specific controller receives those OFPT_FLOW_REMOVED messages." So as per my understanding OFPTC_VACANCY_EVENTS set as config property will generate vacancy_events using OFPT_TABLE_STATUS message type and reason OFPTR_VACANCY_DOWN/OFPTR_VACANCY_UP for that table, but only those controller will receive those events which have OFPT_TABLE_STATUS messages turned on via OFPT_SET_ASYNC message. Thanks and Regards, Saloni Jain Tata Consultancy Services Mailto: saloni.j...@tcs.com Website: http://www.tcs.com ____________________________________________ Experience certainty. IT Services Business Solutions Consulting ____________________________________________ -----Ben Pfaff <b...@nicira.com> wrote: ----- To: Saloni Jain <saloni.j...@tcs.com> From: Ben Pfaff <b...@nicira.com> Date: 07/14/2015 10:45AM Cc: dev@openvswitch.org, Partha Datta <partha.da...@tcs.com>, Deepankar Gupta <deepankar.gu...@tcs.com> Subject: Re: ovs-ofctl mod-table commands supporting OF1.4 Eviction and Vacancy-Events On Mon, Jul 13, 2015 at 08:23:45AM -0700, Ben Pfaff wrote: > On Mon, Jul 13, 2015 at 04:19:46PM +0530, Saloni Jain wrote: > > 2. ovs-ofctl -O Openflow14 mod-table <br> <table_id> vacancy-<low..high> > > -- To be implemented > > OFPTC14_VACANCY_EVENTS is the only set table-mod config property and > > eviction if configured previously will get unset. > > I don't think it's good for mod-table to affect properties that the user > didn't request. I suggest that "ovs-ofctl table-mod" should, when > necessary, first use an OFPMP_TABLE_DESC request to obtain the current > configuration, then modify it according to the user's request. Actually, let me take that back. I think that OFPTC14_VACANCY_EVENTS should be implemented on a per-OpenFlow connection basis. That is, if a controller turns on OFPTC14_VACANCY_EVENTS, then this should affect its connection only; no other connections should receive the vacancy events. That makes more sense to me than to have an ovs-ofctl call affect all subsequent OpenFlow connections (in either direction), because a given controller is the only entity that knows whether it wants to receive vacancy events. =====-----=====-----===== Notice: The information contained in this e-mail message and/or attachments to it may contain confidential or privileged information. If you are not the intended recipient, any dissemination, use, review, distribution, printing or copying of the information contained in this e-mail message and/or attachments to it are strictly prohibited. If you have received this communication in error, please notify us by reply e-mail or telephone and immediately and permanently delete the message and any attachments. Thank you _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
