> -----Original Message----- > From: devel-boun...@open-fcoe.org [mailto:devel-boun...@open-fcoe.org] > On Behalf Of Eric Multanen > Sent: Tuesday, December 15, 2009 10:31 AM > To: de...@open-fcoe.org > Subject: [Open-FCoE] [fcoemon PATCH v2 00/11] rfcoemon restructuring > > v2 - restore code in the service script which destroys FCoE interfaces > for > which DCB is not required when the service is stopped. > > This patch set provides a fairly significant redesign of fcoemon. > fcoemon > was suffering from a number of issues, including being too reactive to > events. This resulted in unstable behavior. This note describes the > high > level functions of the redesigned fcoemon. The following patches > provide the > implementation. > > fcoemon will now have the following high level structure: > 1. Read in FCoE interface configuration files. This information is > used > to create a list of FCoE interfaces. As link and dcbd events > occur and dcbd queries are resolved, the FCoE interface list will > manage > the creation and destruction of FCoE interfaces. Each FCoE > interface > element in the list keeps track of its network interface (from the > config file and could be a VLAN), its real network interface (found > from link events during runtime), and its next action (create, > destroy, > etc.). > > 2. As link events are received from the system, fcoemon determines > which ones > are relevent for the FCoE interfaces. Relevent link events are > those which > occur on interfaces which are configured to be FCoE interfaces (see > the FCoE interface list above), or on the underlying real network > interface, > if the FCoE interface is configured on a VLAN. A list of relevant > real > network interfaces is maintained. The list is used to track the > operstate of the real network interfaces and, if DCB is required, > the status of dcbd queries for the real network interface. > > 3. The core loop of fcoemon: > - listens for link events from rtnetlink and updates the state of > the > real network interface list. Link down events will terminate > any > pending dcbd query sequences and a subsequent link up will > start the > sequence over from the beginning. Delete link events (VLAN > deleted, > driver unloaded) will mark the FCoE interface for destruction. > - listens for dcbd events and response messages. If the response > matches the current dcbd query state, then move to the next > state. > If a dcbd event indicates a change in a DCB feature of interest, > then start the dcbd query sequence over. > - manages a timeout for maintaining a connection to dcbd. If the > dcbd > service stops, this timeout will clean up as needed and re- > establish > the dcbd connection once dcbd starts up again. > - at the end of each event/timeout cycle, after all link and dcbd > and network interface events have been handled, perform any > pending next actions. > For network interface elements, that could mean sending the > next > dcbd query, or, if the dcbd queries are complete, analyze the > results and determine if the FCoE interface should be > will now handle all FCoE interfaces whether or not DCB is > required. > For FCoE interfaces, this means creating or destroying the FCoE > interface. > > 4. All FCoE interfaces, whether DCB is required or not, will be > managed by > fcoemon now. Previously, the init.d start script would handle > configured > FCoE interfaces which were configured without DCB required. > > > dcbd query sequence > =================== > When DCB is required for an FCoE interface, the real network device > performs a > series of dcbd queries to obtain the current DCB configuration. The > sequence > is as follows: > 1. DCB state - is DCB enabled on the interface? > 2. PFC configuration (Priority Flow Control) > 3. FCoE configuration > 4. PFC operational state > 5. FCoE operational state > > If an error occurs at any step, or if all the steps are completed and > the > dcbd state does not match the conditions to either create or destroy > the > FCoE interface (see next sections), then a retry timer is started. > Once the > timer expires, the dcbd query sequence is reinitiated from the > beginning. The > timer begins at 0.2 seconds and increases by multiples of that amount > up to > ten retries. Once the max retries has been reached, without a > successful > completion of the dcbd query sequence, then the FCoE interface is > marked for > destruction. > > The function of this retry mechanism is to protect against destroying > the > FCoE interface due to intermittent problems. Such as when links go > down > momentarily due to configuration changes. When this occurs, dcbd may > take > a couple seconds to resynchronize with the peer device. > > > Required conditions to create an FCoE interface > =============================================== > 1. Link is up on the network interfaces required for the FCoE > interface, and > > 2a. DCB is not required. > OR > 2b. DCB is required > AND DCB is enabled > AND PFC is enabled > AND App:FCoE is enabled > AND PFC and App:FCoE are operational > AND PFC and App:FCoE operational values match > > > Required conditions to destroy an FCoE interface > ================================================ > 1. The network interface required for the FCoE interface is removed > Such as driver is unloaded or VLAN interface is destroyed. > This is detected by DELLINK rtnetlink events. > > 2. The network interfaces required for the FCoE interface are up, > AND DCB is required, > AND on root network interface > DCB is disabled > OR > App:FCoE is disabled > OR > PFC and App:FCoE are operational > AND PFC and App:FCoE operational values mismatch > > 3. When DCB is required and the conditions to create the FCoE > interface are > not satisfied after going through the maximum number of retry > sequences, > as described in the "dcbd query sequence" section, then the FCoE > interface > will be destroyed. > > --- > > Eric Multanen (11): > Update version string of fcoemon. > Remove FCoE interface management from service start script > Add dcbd query timeout and retry mechanism > Update the fcoemon state machine to be insensitive to > intermittent dcb changes > Update the FCoE and network interface lists. > Add separate arguments to specify FCoE and network interface > Fix the print_errors() routine > Remove extraneous dcb members from the network interface > structure. > Fixup dcbd connection timeout code > Remove unused dcbd routine. > Obtain the real device of a VLAN interface using an ioctl. > > > etc/initd/initd.fedora | 66 -- > etc/initd/initd.suse | 37 - > fcoemon.c | 1504 ++++++++++++++++++++++------------------ > -------- > fcoemon.h | 67 +- > fcoeplumb.in | 121 ++-- > 5 files changed, 789 insertions(+), 1006 deletions(-) > > -- > Signature: Eric Multanen <eric.w.multa...@intel.com> > _______________________________________________ > devel mailing list > de...@open-fcoe.org > http://www.open-fcoe.org/mailman/listinfo/devel
Shouldn't the requirement to administer DCB be FCoE independent ? After all DCB is required for other protocols like iscsi as well. How about using a library interface to manage DCB over a network interface so that both open-iscsi and open-fcoe could administer DCB? -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.