From: David Daney <ddaney@caviumnetworks.com>
To: Joe Perches <joe@perches.com>
Cc: David Daney <ddaney.cavm@gmail.com>, <netdev@vger.kernel.org>,
"David S. Miller" <davem@davemloft.net>,
<linux-mips@linux-mips.org>, David Daney <david.daney@cavium.com>
Subject: Re: [PATCH 1/2] netdev: octeon_mgmt: Correct tx IFG workaround.
Date: Wed, 19 Jun 2013 18:47:34 -0700 [thread overview]
Message-ID: <51C25F36.1040202@caviumnetworks.com> (raw)
In-Reply-To: <1371692239.2146.7.camel@joe-AO722>
On 06/19/2013 06:37 PM, Joe Perches wrote:
> On Wed, 2013-06-19 at 18:28 -0700, David Daney wrote:
>> On 06/19/2013 06:08 PM, Joe Perches wrote:
>>> On Wed, 2013-06-19 at 17:40 -0700, David Daney wrote:
>>>> From: David Daney <david.daney@cavium.com>
>>>>
>>>> The previous fix was still too agressive to meet ieee specs. Increase
>>>> to (14, 10).
>>> []
>>>> diff --git a/drivers/net/ethernet/octeon/octeon_mgmt.c b/drivers/net/ethernet/octeon/octeon_mgmt.c
>>> []
>>>> @@ -1141,10 +1141,13 @@ static int octeon_mgmt_open(struct net_device *netdev)
>>>> /* For compensation state to lock. */
>>>> ndelay(1040 * NS_PER_PHY_CLK);
>>>>
>>>> - /* Some Ethernet switches cannot handle standard
>>>> - * Interframe Gap, increase to 16 bytes.
>>>> + /* Default Interframe Gaps are too small. Recommended
>>>> + * workaround is.
>>>> + *
>>>> + * AGL_GMX_TX_IFG[IFG1]=14
>>>> + * AGL_GMX_TX_IFG[IFG2]=10
>>>
>>> Why isn't the TX IFG just 96 bit times?
>>
>> I don't have a full understanding of how the transistors are wired up on
>> the chip, so I cannot accurately answer your question. But I can say
>> that after I empirically found the previous values to get the thing to
>> work, the hardware designers independently found that the values
>> supplied in this patch are required to achieve industry standard IFGs
>> with this hardware.
>
> For one specific chip or for the Octeon entire family?
>
You will notice, if you look at the code, that there is an if statement
that controls which chips get the special IFG treatment.
But to summarize: Only chips that have 1Gig MII ports are affected.
Older versions (that only support 10M and 100M) do not get the adjustment.
David Daney
WARNING: multiple messages have this Message-ID (diff)
From: David Daney <ddaney@caviumnetworks.com>
To: Joe Perches <joe@perches.com>
Cc: David Daney <ddaney.cavm@gmail.com>,
netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
linux-mips@linux-mips.org, David Daney <david.daney@cavium.com>
Subject: Re: [PATCH 1/2] netdev: octeon_mgmt: Correct tx IFG workaround.
Date: Wed, 19 Jun 2013 18:47:34 -0700 [thread overview]
Message-ID: <51C25F36.1040202@caviumnetworks.com> (raw)
Message-ID: <20130620014734.L6_geQfp3rfO84S110-mYbiFl7lNTP-RyTMtf5Q54LU@z> (raw)
In-Reply-To: <1371692239.2146.7.camel@joe-AO722>
On 06/19/2013 06:37 PM, Joe Perches wrote:
> On Wed, 2013-06-19 at 18:28 -0700, David Daney wrote:
>> On 06/19/2013 06:08 PM, Joe Perches wrote:
>>> On Wed, 2013-06-19 at 17:40 -0700, David Daney wrote:
>>>> From: David Daney <david.daney@cavium.com>
>>>>
>>>> The previous fix was still too agressive to meet ieee specs. Increase
>>>> to (14, 10).
>>> []
>>>> diff --git a/drivers/net/ethernet/octeon/octeon_mgmt.c b/drivers/net/ethernet/octeon/octeon_mgmt.c
>>> []
>>>> @@ -1141,10 +1141,13 @@ static int octeon_mgmt_open(struct net_device *netdev)
>>>> /* For compensation state to lock. */
>>>> ndelay(1040 * NS_PER_PHY_CLK);
>>>>
>>>> - /* Some Ethernet switches cannot handle standard
>>>> - * Interframe Gap, increase to 16 bytes.
>>>> + /* Default Interframe Gaps are too small. Recommended
>>>> + * workaround is.
>>>> + *
>>>> + * AGL_GMX_TX_IFG[IFG1]=14
>>>> + * AGL_GMX_TX_IFG[IFG2]=10
>>>
>>> Why isn't the TX IFG just 96 bit times?
>>
>> I don't have a full understanding of how the transistors are wired up on
>> the chip, so I cannot accurately answer your question. But I can say
>> that after I empirically found the previous values to get the thing to
>> work, the hardware designers independently found that the values
>> supplied in this patch are required to achieve industry standard IFGs
>> with this hardware.
>
> For one specific chip or for the Octeon entire family?
>
You will notice, if you look at the code, that there is an if statement
that controls which chips get the special IFG treatment.
But to summarize: Only chips that have 1Gig MII ports are affected.
Older versions (that only support 10M and 100M) do not get the adjustment.
David Daney
next prev parent reply other threads:[~2013-06-20 1:47 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-20 0:40 [PATCH 0/2] netdev: octeon_mgmt minor fixes David Daney
2013-06-20 0:40 ` [PATCH 1/2] netdev: octeon_mgmt: Correct tx IFG workaround David Daney
2013-06-20 1:08 ` Joe Perches
2013-06-20 1:28 ` David Daney
2013-06-20 1:37 ` Joe Perches
2013-06-20 1:47 ` David Daney [this message]
2013-06-20 1:47 ` David Daney
2013-06-20 0:40 ` [PATCH 2/2] netdev: octeon_mgmt: Fix structure layout for little-endian David Daney
2013-06-20 9:47 ` David Laight
2013-06-20 9:47 ` David Laight
2013-06-27 10:40 ` Ralf Baechle
2013-06-20 5:13 ` [PATCH 0/2] netdev: octeon_mgmt minor fixes David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51C25F36.1040202@caviumnetworks.com \
--to=ddaney@caviumnetworks.com \
--cc=davem@davemloft.net \
--cc=david.daney@cavium.com \
--cc=ddaney.cavm@gmail.com \
--cc=joe@perches.com \
--cc=linux-mips@linux-mips.org \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox