Received-SPF: pass (google.com: domain of linux-kernel+bounces-213068-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Message-ID: <bb1156fa-41eb-473b-bbdb-975765008d13@intel.com>
Date: Thu, 13 Jun 2024 12:58:48 +0200
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH iwl-next 11/12] idpf: convert header split mode to libeth
 + napi_build_skb()
To: Jakub Kicinski <kuba@kernel.org>
CC: <intel-wired-lan@lists.osuosl.org>, Tony Nguyen
	<anthony.l.nguyen@intel.com>, "David S. Miller" <davem@davemloft.net>, "Eric
 Dumazet" <edumazet@google.com>, Paolo Abeni <pabeni@redhat.com>, Mina Almasry
	<almasrymina@google.com>, <nex.sw.ncis.osdt.itp.upstreaming@intel.com>,
	<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>
References: <20240528134846.148890-1-aleksander.lobakin@intel.com>
 <20240528134846.148890-12-aleksander.lobakin@intel.com>
 <20240529184012.5e999a93@kernel.org>
From: Alexander Lobakin <aleksander.lobakin@intel.com>
Content-Language: en-US
In-Reply-To: <20240529184012.5e999a93@kernel.org>
Content-Type: text/plain; charset="UTF-8"
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?anZjZXgwZlZXcnhzV1RIV2ZPd2NKaG5WS2xUTFA4RVBGNHJrWWE4aVNJYkNm?=
 =?utf-8?B?enIrV3JOcXZmbk1xZDRTL1A3eTJHYjRndmE5UGVGazk0T001cGNTeXdSOGxz?=
 =?utf-8?B?ck5DdVJJRVBLamtkWTZrMzR4QXBzcWkwMUtCNEtyTklmZkFoWDRTb3p3dWR1?=
 =?utf-8?B?MFR2MmZPQUxiN28vMUNJeFdaMElOREhvaU84SkhkL1krTXBzZytGVHJSbyty?=
 =?utf-8?B?TE5KUXRPVGxDRCt5bUM2bi83clJrRzJNd2RSVFBTS3d2QUdBaTNxY1U5M2Y2?=
 =?utf-8?B?aVpEbUNSR09HYUJCRElYZWpWcENZNXEzMldHcEhTbW9MWFJrSmxMOXk0OE5a?=
 =?utf-8?B?czFWNkNXTlowemc2dFJzc2FRMjk5ZW5wWlNUMmZNWkwrdWFYTm1kdlZRQ2xp?=
 =?utf-8?B?amQ4Q2R2N2RXZ2llcGpwN1UvMkhUWnplNSt3c0VTS2FaelVQNTM4alEvZ1B6?=
 =?utf-8?B?dWwwendJWDRGczNuRVljb1BIa1B1MEFndEZ4SHcvc3RHcGd1aDBVOUF3MzRi?=
 =?utf-8?B?QUFFV29Ha20vUXpDUzl2anZORW1XMklQRjArdjBlc1hOVVZjS0VvbDNSdEhs?=
 =?utf-8?B?aG1FT01tTk0yYjdQNXZ4N0tUVnMzdWJXRDRXZVgrc053eVJ5eEpFdUR3ZFgv?=
 =?utf-8?B?QmlrWng4ZUNBV05KN0dnZHNmN1ZDWm9CN1RoWlYwNnQ2akE5OEZTMHFsYW9K?=
 =?utf-8?B?cTZYVFRPbkRwSjJWTS9ydklSNnZVOVVyVll3UlJKSGszRW9ZRDdiZ2xQeEZL?=
 =?utf-8?B?ZjZjbW51dnFpRFlwaDh3Z1dtTUZ3N3J4KzFpelNXa1pZTU9FK1YrcC9nVXFu?=
 =?utf-8?B?UXZtcGhUSmg4eE9zcUVVMk85ZTNvK2lZdHhsd2Q2cFJWMjJnbXhtQXg0VFVl?=
 =?utf-8?B?cHVWVU9HODFPZEY4dmZLVnV1T3JrN1JrWU1aODJvWjJVZWxNbFA4UG1YZzdP?=
 =?utf-8?B?dXNyUHRXc3pJc0o5ZDZ6WHdibzJZYXdsdmNtKzdPa3BnVHJjUml3QXNyVkk3?=
 =?utf-8?B?eWx5RzBYK1R0ekxXeE8zL0lPbHVXamJacTJrdXpUNkc4Um9IdG5DTFBSYk9l?=
 =?utf-8?B?M21OZ3E4VzBtaFBOZWNyYUx2c3RBYnlJaHhiZEZJOGtRamFsczNrOUV1ZEh1?=
 =?utf-8?B?Wklnb2RBV3ZrbUpFUU9XS2UwekVheHlCNWI4ZjNYUG5kbkJwNWpkZ2VXb1dp?=
 =?utf-8?B?ZE1FUUppODZZelJoQjg3aEZ1azhxem9zSk9lSXZxUkp1Sm9xTW5vaEdrMmdC?=
 =?utf-8?B?bWM0dWJNaWVVM1MxRFE4NWtRbW9IU1Q1U0U2TS9HOElBZ2V3bmcrTDhoaXF0?=
 =?utf-8?B?bG53QWI1bXpFTjZzM3o2d1RGcFM5VFozemp1NktOV3ZCNW12SFRKMVJDRVlq?=
 =?utf-8?B?a1dYOWZ3ajc2azlDZzBvbVo0Vjl0RUgxZTRXdnNmcFhqU041ZTBIZ0hFTUxx?=
 =?utf-8?B?aGJ3Vk04M0lwQmJjTXNCbkVtd3hlVS9QNm0rdW5EbkdxYmg1LzR5MGx0eDRn?=
 =?utf-8?B?OUQyYTNkZjJqWEdZaVRYTWZsSkVCRk9YREN4WjNlbXZaeG9DbTVPOTRuUU1V?=
 =?utf-8?B?ZXBweFlVZW43TVBpMkNYN0g0MkJZK3hoR29obkYyVktSTDQ1cGJwZ1cvK0d4?=
 =?utf-8?B?ZlRwM3grRWl4MHRDUlNKa1lOeHkwM20yZEg2cEJLWlFIUUZjRjdodkI1MjFY?=
 =?utf-8?B?YzRueUliSm5leFRxVXl6dXQyNjFzaUtRQ1pnTmZQdjI5ZDlxYy9WMVRacEF5?=
 =?utf-8?B?UXJ4cmo4S2t4SWxjSDdvWmZtcXFMcy9iSS9BZk9mbWUvei9UcmxFTG5JVjY4?=
 =?utf-8?B?NU11QUhBaDB2UHJFSTJHaDNaU0gvR3hiVXR6UjU5VjMwRDhHd1FKUEhiV3hr?=
 =?utf-8?B?M3FGSDcrVkFmSVVpci9Jak5Tdi9Zb1htdDJmakFqeHJmbE9KMFlvZHZpTHZj?=
 =?utf-8?B?WFBoOSsxQkNxYUhFb1ovYmFwa09MczNBc2xmazMyT1psdlBlYzNhWVMwKzhl?=
 =?utf-8?B?UG9KektVTWw2V2kyc2M4UnlrVmFkTXpFT0VOUWxLbkRQREQxbnZQTHJtcFlR?=
 =?utf-8?B?TnVVeVF1VWpxL3FsRnFMVGZDcFlydHpWdW81UTF1NGduY0cxNmtVUWdDQTdU?=
 =?utf-8?B?ajJPWU1FaVhSRkIyLzNlNXlmZmRLTXBMVmtxcXhGYnpPaEx6T2Z6SXFSb2lk?=
 =?utf-8?B?U0E9PQ==?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 16b4cbeb-62dd-4f3f-3c0f-08dc8b97de00
X-MS-Exchange-CrossTenant-AuthSource: DS0PR11MB8718.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jun 2024 10:59:16.1677
 (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: 9UnZpCU+Um9tdpcPl9C36PcjKxyc1WJvtvAFqxmvPUUJqrri8HEsaAUamOUX1QKqDYsIZr6m5qkvj10XjQjRNKfneG7VTT/uQx+zTfYUQjE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR11MB6547
X-OriginatorOrg: intel.com

From: Jakub Kicinski <kuba@kernel.org>
Date: Wed, 29 May 2024 18:40:12 -0700

> On Tue, 28 May 2024 15:48:45 +0200 Alexander Lobakin wrote:
>> Currently, idpf uses the following model for the header buffers:
>>
>> * buffers are allocated via dma_alloc_coherent();
>> * when receiving, napi_alloc_skb() is called and then the header is
>>   copied to the newly allocated linear part.
>>
>> This is far from optimal as DMA coherent zone is slow on many systems
>> and memcpy() neutralizes the idea and benefits of the header split. Not
>> speaking of that XDP can't be run on DMA coherent buffers, but at the
>> same time the idea of allocating an skb to run XDP program is ill.
>> Instead, use libeth to create page_pools for the header buffers, allocate
>> them dynamically and then build an skb via napi_build_skb() around them
>> with no memory copy. With one exception...
>> When you enable header split, you except you'll always have a separate
> 
>                                     accept

"expect" :D Thanks for spotting, nice catch.

> 
>> header buffer, so that you could reserve headroom and tailroom only
>> there and then use full buffers for the data. For example, this is how
>> TCP zerocopy works -- you have to have the payload aligned to PAGE_SIZE.
>> The current hardware running idpf does *not* guarantee that you'll
>> always have headers placed separately. For example, on my setup, even
>> ICMP packets are written as one piece to the data buffers. You can't
>> build a valid skb around a data buffer in this case.
>> To not complicate things and not lose TCP zerocopy etc., when such thing
>> happens, use the empty header buffer and pull either full frame (if it's
>> short) or the Ethernet header there and build an skb around it. GRO
>> layer will pull more from the data buffer later. This W/A will hopefully
>> be removed one day.
> 
> Hopefully soon, cause it will prevent you from mapping data buffers to
> user space or using DMABUF memory :(

Correct. The HW team is informed and some work on it is happening right
now. I told them that stuff like devmem etc., i.e. when the kernel
doesn't have access to the data buffers, will just choke on this.

I mean, I don't care about unknown packet types since it's very unlikely
and it's almost always some garbage, as well as when the header doesn't
fit into 256 bytes (I can't imagine such situation with known protocols,
but if it can happen, I can bump to 512 or so), but currently, and it's
a shame, idpf does header split only for TCP/UDP/SCTP, on my setup it
didn't want to split even regular ICMP, although it parsed the type
correctly =\ I dunno why they did it this way.
There are some configuration bits which in theory allow you to enable
hsplit for other types of frames, but enabling them didn't change
anything unfortunately.

Thanks,
Olek