Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38;
Message-ID: <d8631d76-4bb3-41a4-a2b2-86725867d2a9@intel.com>
Date:   Thu, 30 Nov 2023 12:58:27 +0100
User-Agent: Mozilla Thunderbird
Subject: Re: [Intel-wired-lan] [PATCH net-next v5 03/14] page_pool: avoid
 calling no-op externals when possible
Content-Language: en-US
To:     Yunsheng Lin <linyunsheng@huawei.com>
CC:     Christoph Hellwig <hch@lst.de>,
        Paul Menzel <pmenzel@molgen.mpg.de>,
        Maciej Fijalkowski <maciej.fijalkowski@intel.com>,
        Jesper Dangaard Brouer <hawk@kernel.org>,
        Larysa Zaremba <larysa.zaremba@intel.com>,
        <netdev@vger.kernel.org>, Alexander Duyck <alexanderduyck@fb.com>,
        "Ilias Apalodimas" <ilias.apalodimas@linaro.org>,
        <linux-kernel@vger.kernel.org>, Eric Dumazet <edumazet@google.com>,
        Michal Kubiak <michal.kubiak@intel.com>,
        <intel-wired-lan@lists.osuosl.org>,
        David Christensen <drc@linux.vnet.ibm.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>,
        "David S. Miller" <davem@davemloft.net>
References: <20231124154732.1623518-1-aleksander.lobakin@intel.com>
 <20231124154732.1623518-4-aleksander.lobakin@intel.com>
 <6bd14aa9-fa65-e4f6-579c-3a1064b2a382@huawei.com>
 <a1a0c27f-f367-40e7-9dc2-9421b4b6379a@intel.com>
 <534e7752-38a9-3e7e-cb04-65789712fb66@huawei.com>
 <8c6d09be-78d0-436e-a5a6-b94fb094b0b3@intel.com>
 <4814a337-454b-d476-dabe-5035dd6dc51f@huawei.com>
From:   Alexander Lobakin <aleksander.lobakin@intel.com>
In-Reply-To: <4814a337-454b-d476-dabe-5035dd6dc51f@huawei.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?cGdzMWRDUS8veGROVUJwTkJqVUY0cFduRGhaWWIzYzQwSW5iMTlrN0c4ZHdL?=
 =?utf-8?B?OW5YaXgxcEZHY3NJRjZHcGJhVnRDQUVSZ2YzQ1d0YlhMc3RPSE5iVGFhVXFO?=
 =?utf-8?B?SlB2NzN6QWJXci9mSWVUb0ZiYkcvaDhsK3hhZHlMVEpPWVdqYSs3UXR0d2pw?=
 =?utf-8?B?V3M2SHJzOFBKSUhGdXdPdE5udGhyNEQxeXJ2MC9hM0ptWEVuUlA0cU4zaGty?=
 =?utf-8?B?UzRJcmx4SW9RTWpSRlk4S3lONm9xUHZZOS8xUXhnd0JRVXowQjhLWWpyWlB2?=
 =?utf-8?B?RVVsRk05aEdWZlU5M1VqN3Z2b1RwWkFYeDRhNkFZd0JMMW5JbTVzejlOYU10?=
 =?utf-8?B?T3Y2bWpFNUZjVStSNmhMNEdDWitaZmRDMUhUQzA0YXRXV2k2RjVTQUZGYUVq?=
 =?utf-8?B?UjZsb3hCTkJiOWRvNEtHbmlBRTR1dVZxLzRlZEpqK08yWi8vaTZxZnBjT3lC?=
 =?utf-8?B?dlFOZXZEUTIycVROOVltNkNkaUpuUkVhQUw3bDdza0JSZm8rQWpwQzJ4SWl3?=
 =?utf-8?B?YnZtbHBGckhTaVJjWlZ1Vm5KK254akIzeFZDWW1aMEdrcnRSUHNVU0Q0amVY?=
 =?utf-8?B?UG5BR0dybU1NSjJ4RWg0RFRRcXpScVVvTTAxMkhMRm9GRW5HcnVMSFdVUTh1?=
 =?utf-8?B?Y3pubDhxTVFLbm45VUh1UGs5U252VHJobVl2aVY2STlKTG1uZG8xVjh2Zjgw?=
 =?utf-8?B?ZnEzaFlwWE8vYzJDOVRrRW5KUXU0em9QQ0w1MW1zdGk5VmRyS09sWmoxRzZC?=
 =?utf-8?B?UlJNVHNHUUNQMTZ2RTNYYzZwUnloK2s2d2RhVmJ3UExmeDlTYnVzVjU0dGZ2?=
 =?utf-8?B?eWtLSjFjd0dVUEx3dUFYbXFkQ0prdE95VXJPUVFhcE42bVhpNllRN1hoSHVH?=
 =?utf-8?B?YmNIV2I1RndPbHJVR2p1cTJtdEtrOHJnNEVwR1luV3R4c3BzQUp1UEFUa2kv?=
 =?utf-8?B?UFBTMjNVNGdzdmwxaDgwbkZFUFVGTnRZYnZ4ZnJmWTNGNG0zUGpYcWQ2TDlQ?=
 =?utf-8?B?cEJZeUxmb2JlVW1XVGRmMkpPRjlOcFl3dzI2T1BMRU1pdkthVU5wUWZLT05U?=
 =?utf-8?B?cWtiRTc5bXhpeVdoUFJXMDdBNGJ3bXlFc0Q3MGhVR280Q0NCL0JrdXNCT1Vn?=
 =?utf-8?B?cFhXZTJKZnFTWEZkc0pvOFUyRmp0dW9vRlJRQXExdmVxbWZiMFBCaDgxczNV?=
 =?utf-8?B?U2dVNDBiLzFJajQ0amhFaUhpUXVOdnBkMnB2VkNiRmZtdDVCUytGVTJaSHJi?=
 =?utf-8?B?Vk1XYllRUEtnTThaOURCeVdER2FOOTlOMVBFOVo5djViTWJQQ2t4akZhZUI3?=
 =?utf-8?B?b1ZGcU4yUDVVRHRKcXEvanBIOGtsNTBLTmNLdXZya2s1VlgxRm1RSnllcW5I?=
 =?utf-8?B?aEZvZ1QyOUVoSjA1cVNtUEI2eU42dHJwb2RjdFBySnB4MEJtaTJGUnlmK2JL?=
 =?utf-8?B?WTlPTFRwU0llZ3J1TVRGN2Y5M2UwR3dCK01xM3RSeFlXdzRoM1RHTjcxTjY0?=
 =?utf-8?B?NHdKUVJ2V3A5NXZsZURoQVFpNVlmUlBYb1VXOXJ1aG8zZHk5ZXZsMWRDU0g3?=
 =?utf-8?B?VWx6WWJYR3MxSTBiSnA4L09TSzRCckVCcDEycjBlSmxxcDNwL2VkYnNheXV1?=
 =?utf-8?B?TlhQZVo1blZtS1duU1RxSTRLcHA5MWVoWlllZlNXZTA1RTFIMEo0REZ4WEVo?=
 =?utf-8?B?QnhtbUxWNTVxTE9JM1BwVElTcTlJenUwbmVib3lHV0JOeVJTUWMwMWw3K2tn?=
 =?utf-8?B?QjNDNlQ5QU11SnNJTkI2ZHdtK05BOWdrVVpHb2MzVTQzWTgzM2NKMFRTR0JQ?=
 =?utf-8?B?a0g3MUJMclAzOWJQTEVzRFFBa1NpaVVHMEhtbnRRK3N6dDZEYWF2MTRaeEIz?=
 =?utf-8?B?Z21IbytoMDkvVXdhTU8yR0JMNU1PUWhMakYvcG5aWkhMRjlMLy9FUnVOZjM1?=
 =?utf-8?B?RlovMnlVcHVML2xHRE1BVDFDakNKQm56YkhFUUtJV2JUaG9OcUtLRWhNMXZp?=
 =?utf-8?B?NTJGSW13WHF1K1pBdStUYjQwbnBhNEhhd21MdmUzN0xuODJRUGt6b2V1MjY3?=
 =?utf-8?B?UmMwVlR2cWp0Qy9uZG11a2t2RWRQVDVGUnM4RFRiQ213RFd0c081aldDY0M5?=
 =?utf-8?B?M25yYzJ6Uy9mSTR4Tk5QcjZIbUQrTmhmV2w3OEt4eHRLRmYrRjRxc3ZPWWJr?=
 =?utf-8?B?N1E9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 73c0c545-f19c-42ad-8f26-08dbf19bc7a4
X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB3625.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Nov 2023 11:59:17.6814
 (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: ecfIh1gulhZYmXm5CrAdQ04N0GEDUu67AVw8USGSQuNDiS3FUeDh6goBcTuJx9rq8Vt6pvWjVj+C2nN/IZKmTLD6Z0wHfkfe8NU4yN3MdDM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH8PR11MB6706
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE
	autolearn=unavailable autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Thu, 30 Nov 2023 03:59:52 -0800 (PST)

From: Yunsheng Lin <linyunsheng@huawei.com>
Date: Thu, 30 Nov 2023 16:46:11 +0800

> On 2023/11/29 21:17, Alexander Lobakin wrote:
>> From: Yunsheng Lin <linyunsheng@huawei.com>
>> Date: Wed, 29 Nov 2023 11:17:50 +0800
>>
>>> On 2023/11/27 22:32, Alexander Lobakin wrote:
>>>>
>>>> Chris, any thoughts on a global flag for skipping DMA syncs ladder?
>>>
>>> It seems there was one already in the past:
>>>
>>> https://lore.kernel.org/netdev/7c55a4d7-b4aa-25d4-1917-f6f355bd722e@arm.com/T/
>>
>> It addresses a different problem, meaningless indirect calls, while this
>> one addresses meaningless direct calls :>
>> When the above gets merged, we could combine these two into one global,
>> but Eric wasn't active with his patch and I remember there were some
>> problems, so I wouldn't count on that it will arrive soon.
> 
> I went through the above patch, It seems to me that there was no
> fundamental problem that stopping us from implementing it in the dma
> layer basing on Eric' patch if Eric is no longer interested in working
> on a newer version?

I'm somewhat interested in continuing working on Eric's patch, but not
now. Have some urgent projects to work on, I could take this in January
I guess...
This PP-specific shortcut was done earlier and gives good boosts. It
would be trivial to remove it together with the XSk shortcut once a
generic both indirect and direct call DMA shortcut lands.
Does this sounds good / justified enough? Or you and other
reviewers/maintainers would prefer to wait for the generic one without
taking this patch?

> 
> It is just that if we allow every subsystem and driver using dma API
> doing their own trick of skipping dma sync, then there is less willing
> to implement it in the dma layer.

Thanks,
Olek