Received-SPF: pass (google.com: domain of linux-kernel+bounces-170742-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Message-ID: <d2d9c0a8-6d4f-4aff-84f3-35fc2bff49b7@intel.com>
Date: Tue, 7 May 2024 09:21:53 +0300
User-Agent: Mozilla Thunderbird
Subject: Re: [Intel-wired-lan] [PATCH v2 1/2] e1000e: let the sleep codes run
 every time
To: En-Wei WU <en-wei.wu@canonical.com>, Sasha Neftin <sasha.neftin@intel.com>
CC: <netdev@vger.kernel.org>, <rickywu0421@gmail.com>,
	<linux-kernel@vger.kernel.org>, <edumazet@google.com>,
	<intel-wired-lan@lists.osuosl.org>, <kuba@kernel.org>,
	<anthony.l.nguyen@intel.com>, <pabeni@redhat.com>, <davem@davemloft.net>,
	"Brandeburg, Jesse" <jesse.brandeburg@intel.com>, "Lifshits, Vitaly"
	<vitaly.lifshits@intel.com>
References: <20240503101824.32717-1-en-wei.wu@canonical.com>
 <7f533913-fba9-4a29-86a5-d3b32ac44632@intel.com>
 <CAMqyJG1Fyt1pZJqEjQN_kqXwfJ+HnqvW1PnAOEEpzoS9f37KBg@mail.gmail.com>
Content-Language: en-US
From: "Ruinskiy, Dima" <dima.ruinskiy@intel.com>
In-Reply-To: <CAMqyJG1Fyt1pZJqEjQN_kqXwfJ+HnqvW1PnAOEEpzoS9f37KBg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?djd5UFNUeG90d2Q3cjRFMXZjTlVjakNUeFc5d2k5bmlIYU1ZUHBETnR3SWZa?=
 =?utf-8?B?VFB4WURHVlkvSGZ6RWNzN20vMXI0WlF3V3V1NVZFdkwzWk9BWHJEeVlGTFdC?=
 =?utf-8?B?MzMvOXBnRk90eUNOUEtKQll2ZzQ2NDZRNnpDRDFkYzVxam9xVTUzZFlMZW9M?=
 =?utf-8?B?S2hDRUNxWWZSWjZpTno3ZFZkMlN1V1VZTnQ5NHZBRmp0RXpFSlRiTlEwWThY?=
 =?utf-8?B?Z2lGL0NKS1dXRHFJemxRN01Hdy9qNkxKTHNHTG1GMjRxZzZ0S2VrbnhKLzBs?=
 =?utf-8?B?UllJQmpmaEY5SFlTZjVwYnhMTS9icDB1MGM5WG5nRDNoSytrM2JPSEVobHYz?=
 =?utf-8?B?UEIzUjBEM0xGTzlaQTlpMkdvNDNvVkgyU2d1N3J3WVRDcVdGMmUxMDFxaytq?=
 =?utf-8?B?K2JEUGtNaHora2ViSGtzaWl0bExWdTM2S0ZVTzFYT0FhREpmdXp2dEJxQzN4?=
 =?utf-8?B?K09za3U0RUdQcUcvN3FYVVdrRmJ1UnBPZDFLclNMckkvbjU3YU12RExCU0Vk?=
 =?utf-8?B?aXQvUWtiajdPTG1waCtzMnBHK3dXVy9nTjlDVGtadkxaSTRHZEFrRkdoRnpt?=
 =?utf-8?B?cUhtT2lHNEVUUEtnMnBwOU5jN2NFcnd6Qk1kSmN1dUpHNysxOHJHRW9CVEJk?=
 =?utf-8?B?OE5MRU56WEJ2OWlIYW9OeVdUY3Q1ZlJNVTVmWHNtamFQTmYwSXdRdUtoellK?=
 =?utf-8?B?NFpnTlZWcFo1OWphMmJuTjYvenBxTmllb3VPM09zOUF6OGFSeTB4bExLRGND?=
 =?utf-8?B?Z1JTVllBZW9wVG1hQmtNVGsyQWFpQ2kzaXJTVDdyMDlhVkhGcHRXU0hVWE1m?=
 =?utf-8?B?NW1MVmpvUlRSbXEwNGFyVmV1Y3hPRnZxenBDd3ltQ0t6VzhDUVFubjNzRjY2?=
 =?utf-8?B?RUkrWDYzOXFZdnR4ZHVzdnpiNHF1R2Z3YVo0cjhSVXJYN0hUZVcwVlJlK0Vr?=
 =?utf-8?B?V2U0QWpOYld3aXFyLzlMU24zRi80Z0hTY3phZVU0MHFldlNvV3RNK2o0SGhE?=
 =?utf-8?B?bDlEQzU3SGJuSHVlVjJXdExjNGlGWkdmbEU4S0hSRFJVN3BzT3N4eUt4Q2RS?=
 =?utf-8?B?VXZxUWlGYmZlUDd1dUhFMXZmQ0tVM3B4RmJhWk1IdjkwUjZBODR5R1d1elZK?=
 =?utf-8?B?NXVqK01wa21wc2QxUEJ4eVRtbS9scXpzUWwxVGkxN3FORXFKczdsY2ZpVWFy?=
 =?utf-8?B?WlJaSVVCTGRhTTByU0NNa1VNN3dvbU1BcFRZOWNnbUNleFM5VndaYkgwOFU4?=
 =?utf-8?B?dGFhTTNNd1RoenpXSlppbk5nWEdDTlYweXFrU1E3RmJNWVdIWUREem9ORG1p?=
 =?utf-8?B?UVNyRCtHYTVPS3hxUlB3eHJkeVNvZkJQNlR1VEdqak5kVXUzc3hlT2g5VzRa?=
 =?utf-8?B?NXN0N2pUYUYxbnZkQkN0OG5OMDc5emN4dTVONnVIVThZaFdjVVJMQXdBek9n?=
 =?utf-8?B?a2ZxVm5ZbElINzFSNGFtR2t4ZVo4YVQ1SytFdGhmUWRPMkd4YWtjN1haanlE?=
 =?utf-8?B?Zm9FVGdrUHJYSTArVlBpZ1lGKzh2OFZvdWVlNkFJUzJMelBrUWxlYXR2dG8r?=
 =?utf-8?B?VWpJaUU0UTA3ZDVFZDcwa1JXclpKdXJ0UVBXdE9oVENldTkydlBBMzZscVUw?=
 =?utf-8?B?cWhJNWh1MEtYQmVmNE01SllFdEh5dUh4SVM2Wk51dkRDdHNyV0IyeXJzdmxR?=
 =?utf-8?B?cnhBcVVkMmdlS2NkR2NkRytBaldLRDIrWEt3Qm9jQVBaWXFCSUEvZmd2Wi9n?=
 =?utf-8?B?MkRnL2gzTlZaVDlFRTF5ejNhcHhCT0Q2ZGRvYlJEYnhwaUNOSlVKbUFzVC9r?=
 =?utf-8?B?N0V3eFNLbm1VQzNIUE9KRjBDTmE2d2tZMlNTRjRpb0pMWnk4MEpMd0ZSWjVh?=
 =?utf-8?B?SnRKWGRSZmN5ckx1aWFsb2J2VlYwb05KRVlvU2x5VWdBek0zbHV1VjFMbVJ0?=
 =?utf-8?B?SGFaeDMxVlJQTXA3aS9nd3JrRzF1N2JTYTl6WjcyelhWOXBhNjhYTDYrL0tR?=
 =?utf-8?B?eXFSK0lrS3VkeVpGSTM0QUdFbmx0WGRmMHp3SHh5bVQ5aDlTMHRlVnoxWWVl?=
 =?utf-8?B?a1Q2NkE5UGVicFdqYU9aNGsyTWp0WnpCT0RuQS9PaUV0ZEdneG1qV0ZJMmg1?=
 =?utf-8?B?RzJqRXhycjA0QjE0by9jYXpBdVZpOEUyWkc5TkZJZ3NxaDFaTGVBTmdhTHhC?=
 =?utf-8?B?MUE9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 8d3ce0fd-9c04-4819-088e-08dc6e5e0000
X-MS-Exchange-CrossTenant-AuthSource: MN0PR11MB6280.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 May 2024 06:21:58.8096
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: bJ7LfFtQFYDDk9CmoY/AGuSkFgwXwaDDqYTMTuViZVqOPrbd3YKAkAe1t07jCU4x5v2sai3+7tia7JgHX+0uqg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY8PR11MB7108
X-OriginatorOrg: intel.com

On 06/05/2024 19:46, En-Wei WU wrote:
> Thank you for your time.
> 
> Originally, sleep codes would only be executed if the first read fails
> or the link status that is read is down. Some circumstances like the
> [v2,2/2] "e1000e: fix link fluctuations problem" would need a delay
> before first reading/accessing the PHY IEEE register, so that it won't
> read the instability of the link status bit in the PHY status
> register.
> 
> I've realized that this approach isn't good enough since the purpose
> is only to fix the problem in another patch and it also changes the
> behavior.
> 
> Here is the modification of the patch [v2,2/2] "e1000e: fix link
> fluctuations problem":
> --- a/drivers/net/ethernet/intel/e1000e/ich8lan.c
> +++ b/drivers/net/ethernet/intel/e1000e/ich8lan.c
> @@ -1428,7 +1428,17 @@  static s32
> e1000_check_for_copper_link_ich8lan(struct e1000_hw *hw)
> - ret_val = e1000e_phy_has_link_generic(hw, 1, 0, &link);
> /* comments */
> + ret_val = e1000e_phy_has_link_generic(hw, COPPER_LINK_UP_LIMIT,
> 100000, &link);
> 
> Do you think we can just add a msleep/usleep_range in front of the
> e1000e_phy_has_link_generic() instead of modifying the sleep codes in
> e1000e_phy_has_link_generic()?
> 
> Thanks.
> 
> On Mon, 6 May 2024 at 23:53, Sasha Neftin <sasha.neftin@intel.com> wrote:
>>
>> On 03/05/2024 13:18, Ricky Wu wrote:
>>> Originally, the sleep codes being moved forward only
>>> ran if we met some conditions (e.g. BMSR_LSTATUS bit
>>> not set in phy_status). Moving these sleep codes forward
>>> makes the usec_interval take effect every time.
>>>
>>> Signed-off-by: Ricky Wu <en-wei.wu@canonical.com>
>>> ---
>>>
>>> In v2:
>>> * Split the sleep codes into this patch
>>>
>>>    drivers/net/ethernet/intel/e1000e/phy.c | 9 +++++----
>>>    1 file changed, 5 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/net/ethernet/intel/e1000e/phy.c b/drivers/net/ethernet/intel/e1000e/phy.c
>>> index 93544f1cc2a5..4a58d56679c9 100644
>>> --- a/drivers/net/ethernet/intel/e1000e/phy.c
>>> +++ b/drivers/net/ethernet/intel/e1000e/phy.c
>>> @@ -1777,6 +1777,11 @@ s32 e1000e_phy_has_link_generic(struct e1000_hw *hw, u32 iterations,
>>>
>>>        *success = false;
>>>        for (i = 0; i < iterations; i++) {
>>> +             if (usec_interval >= 1000)
>>> +                     msleep(usec_interval / 1000);
>>> +             else
>>> +                     udelay(usec_interval);
>>> +
>>
>> I do not understand this approach. Why wait before first
>> reading/accessing the PHY IEEE register?
>>
>> For further discussion, I would like to introduce Dima Ruinskiy (architect)
>>
>>>                /* Some PHYs require the MII_BMSR register to be read
>>>                 * twice due to the link bit being sticky.  No harm doing
>>>                 * it across the board.
>>> @@ -1799,10 +1804,6 @@ s32 e1000e_phy_has_link_generic(struct e1000_hw *hw, u32 iterations,
>>>                        *success = true;
>>>                        break;
>>>                }
>>> -             if (usec_interval >= 1000)
>>> -                     msleep(usec_interval / 1000);
>>> -             else
>>> -                     udelay(usec_interval);
>>>        }
>>>
>>>        return ret_val;
>>

Regarding the usage of sleep/sleep_range functions - they can only be 
used if this code will never be called from an atomic context. I do not 
know if such a guarantee exists.

In general I have quite a few questions and concerns regarding this 
patch series. The comment in patch 2/2 states that it is designed to 
work around a link flap issue with the average time between link up and 
down is 3-4ms, and yet the code waits a whole 100ms before reading the 
PHY bit the first time. Why so long?

Furthermore, if I am reading this right, it appears that, with the 
proposed change, e1000e_phy_has_link_generic will poll the PHY link up 
to 10 times, with 100ms delay between each iteration - until the link is 
up. Won't it lead to wasting all this time, if the link is actually down?

Looking at https://bugzilla.kernel.org/show_bug.cgi?id=218642, at the 
problem this commit series is trying to solve - I wonder:
(1) How serious this problem is. It is normal for link establishment to 
take a few seconds from plugging the cable (due to PHY 
auto-negotiation), and I can accept some link instability during that time.
(2) Assuming the problem is considered serious - have we root-caused it 
correctly.