> -----Original Message-----
> From: Ben Pfaff [mailto:[email protected]]
> Sent: Friday, June 07, 2019 11:03 PM
> To: Nitin Katiyar <[email protected]>
> Cc: [email protected]; Manohar Krishnappa Chidambaraswamy
> <[email protected]>
> Subject: Re: [ovs-dev] [PATCH v2 2/2] Don't send or receive LACP PDUs when
> carrier state of slave is down
>
> On Thu, Jun 06, 2019 at 06:34:21AM +0000, Nitin Katiyar wrote:
> >
> >
> > > -----Original Message-----
> > > From: Ben Pfaff [mailto:[email protected]]
> > > Sent: Wednesday, June 05, 2019 12:03 AM
> > > To: Nitin Katiyar <[email protected]>
> > > Cc: [email protected]; Manohar Krishnappa Chidambaraswamy
> > > <[email protected]>
> > > Subject: Re: [ovs-dev] [PATCH v2 2/2] Don't send or receive LACP
> > > PDUs when carrier state of slave is down
> > >
> > > On Sun, Jun 02, 2019 at 04:14:34PM +0000, Nitin Katiyar wrote:
> > > > Problem:
> > > > ========
> > > > On certain Fortville NICs it has been observed that PHY UP
> > > > detection can get delayed (sometimes up to 4-5 secs). When the
> > > > driver fails to fetch PHY status as UP even though its actually
> > > > UP, LACP packets can get exchanged and LACP slave brought UP. In
> > > > such a case, the remote end would start sending traffic on that
> > > > slave, but OVS drops it, as the bond-slave is not yet enabled due to PHY
> DOWN.
> > > >
> > > > Fix:
> > > > ====
> > > > The main intention here is delay LACP negotiation until carrier
> > > > (PHY) status is read as UP.
> > > >
> > > > 1. When carrier state is DOWN, do not send any LACP PDUs and
> > > > drop any received LACP PDUs.
> > > >
> > > > 2. When LACP PDU is received, trigger re-checking
> > > > of carrier-state (in port_run()) by incrementing the connectivity
> > > > sequence number to find out the true carrier state as fast as
> > > > possible.
> > >
> > > I had to read this patch and the above description a few times.
> > > Maybe I understand it now. Please let me try to re-state it and let
> > > me know if I've got it right.
> > >
> > > Fortville NICs (or perhaps their drivers) do not consistently send
> > > an immediate notification when the PHY comes up. However, packets can
> still be received.
> > > Until now, OVS drops traffic until the notification that the PHY is up
> > > arrives.
> > > This patch changes OVS to respond to receiving a LACP packet on a
> > > device, for which it has not yet been notified that carrier is up,
> > > by immediately polling carrier state. This polling can bypass the
> > > Fortville delayed notification and allow OVS to bring up the bond slave
> faster.
> > It is other way. Until now, OVS (and connected switch) may see LACP in
> negotiated state but OVS may have link/carrier state as DOWN due to
> NIC/driver issue.
> > In this case, NIC/driver didn't update the link UP state for few seconds
> although link had come up and started carrying traffic. This brought up the
> LACP slave and remote end started traffic on this slave. OVS dropped the
> packets as slave status was down.
> > To avoid this situation we propose this patch for not sending/receiving LACP
> PDUs till link is reported UP. In short, we delay LACP negotiation till
> carrier
> status is UP. Additionally, if PMD is receiving LACP PDU when carrier state is
> down it triggers checking of state by changing connectivity sequence number.
>
> OK, let me try again. Is the following correct?
>
> --8<--------------------------cut here-------------------------->8--
>
> Fortville NICs (or their drivers) can get into an inconsistent state, in
> which the
> NIC can actually transmit and receive packets even though they report "PHY
> down". In such a state, OVS can exchange and process LACP messages and
> enable a bond slave. However, further packet exchange over the slave fails
> because OVS sees that the PHY is down.
>
> This commit fixes the problem by making OVS ignore received LACP PDUs and
> suppress transmitting LACP PDUs when carrier is down. In addition, when a
> LACP PDU is received with carrier down, this commit triggers rechecking the
> carrier status (by incrementing the connectivity sequence
> number) to ensure that it is updated as quickly as possible.
This is correct Ben. I will update the patch description.
Regards,
Nitin
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
