[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CO6PR18MB3873E9B317C7833D963C6AC2B0BD9@CO6PR18MB3873.namprd18.prod.outlook.com>
Date: Mon, 25 Jan 2021 07:15:40 +0000
From: Stefan Chulski <stefanc@...vell.com>
To: Andrew Lunn <andrew@...n.ch>
CC: Russell King - ARM Linux admin <linux@...linux.org.uk>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"thomas.petazzoni@...tlin.com" <thomas.petazzoni@...tlin.com>,
"davem@...emloft.net" <davem@...emloft.net>,
Nadav Haklai <nadavh@...vell.com>,
Yan Markman <ymarkman@...vell.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"kuba@...nel.org" <kuba@...nel.org>,
"mw@...ihalf.com" <mw@...ihalf.com>,
"atenart@...nel.org" <atenart@...nel.org>
Subject: RE: [EXT] Re: [PATCH v2 RFC net-next 08/18] net: mvpp2: add FCA
periodic timer configurations
> > >
> > > --------------------------------------------------------------------
> > > -- On Sun, Jan 24, 2021 at 01:43:57PM +0200, stefanc@...vell.com
> > > wrote:
> > > > +/* Set Flow Control timer x140 faster than pause quanta to ensure
> > > > +that link
> > > > + * partner won't send taffic if port in XOFF mode.
> > >
> > > Can you explain more why 140 times faster is desirable here? Why 140
> > > times and not, say, 10 times faster? Where does this figure come
> > > from, and what is the reasoning? Is there a switch that requires it?
> >
> > I tested with 140.
> > Actually regarding to spec each quanta should be equal to 512 bit times.
> > In 10G bit time is 0.1ns.
>
> And if the link has been negotiated to 10Mbps? Or is the clock already scaled
> to the link speed?
>
> Andrew
Currently its static, probably I can add function that reconfigure timer during runtime(based on link speed).
Should it be part of this series or add it afterwards?
Regards,
Stefan.
Powered by blists - more mailing lists