lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 26 Oct 2022 16:27:47 +0200 From: Loic Poulain <loic.poulain@...aro.org> To: haozhe chang <haozhe.chang@...iatek.com> Cc: "chandrashekar.devegowda@...el.com" <chandrashekar.devegowda@...el.com>, "linuxwwan@...el.com" <linuxwwan@...el.com>, "chiranjeevi.rapolu@...ux.intel.com" <chiranjeevi.rapolu@...ux.intel.com>, Haijun Liu (刘海军) <haijun.liu@...iatek.com>, "m.chetan.kumar@...ux.intel.com" <m.chetan.kumar@...ux.intel.com>, "ricardo.martinez@...ux.intel.com" <ricardo.martinez@...ux.intel.com>, "ryazanov.s.a@...il.com" <ryazanov.s.a@...il.com>, "johannes@...solutions.net" <johannes@...solutions.net>, "davem@...emloft.net" <davem@...emloft.net>, "edumazet@...gle.com" <edumazet@...gle.com>, "kuba@...nel.org" <kuba@...nel.org>, "pabeni@...hat.com" <pabeni@...hat.com>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Lambert Wang (王伟) <Lambert.Wang@...iatek.com>, Xiayu Zhang (张夏宇) <Xiayu.Zhang@...iatek.com>, srv_heupstream@...iatek.com Subject: Re: [PATCH] wwan: core: Support slicing in port TX flow of WWAN subsystem On Wed, 26 Oct 2022 at 13:45, haozhe chang <haozhe.chang@...iatek.com> wrote: > > On Wed, 2022-10-26 at 15:28 +0800, Loic Poulain wrote: > > Hi Haozhe, > > > > On Wed, 26 Oct 2022 at 03:16, <haozhe.chang@...iatek.com> wrote: > > > > > > From: haozhe chang <haozhe.chang@...iatek.com> > > > > > > wwan_port_fops_write inputs the SKB parameter to the TX callback of > > > the WWAN device driver. However, the WWAN device (e.g., t7xx) may > > > have an MTU less than the size of SKB, causing the TX buffer to be > > > sliced and copied once more in the WWAN device driver. > > > > The benefit of putting data in an skb is that it is easy to > > manipulate, so not sure why there is an additional copy in the first > > place. Isn't possible for the t7xx driver to consume the skb > > progressively (without intermediate copy), according to its own MTU > > limitation? > > > t7xx driver needs to add metadata to the SKB head for each fragment, so > the driver has to allocate a new buffer to copy data(skb_put_data) and > insert metadata. Normally, once the first part (chunk) of the skb has been consumed (skb_pull) and written to the device, it will become part of the skb headroom, which can then be used for appending (skb_push) the header (metadata) of the second chunks, and so... right? Just want to avoid a bunch of unnecessary copy/alloc here. Regards, Loic
Powered by blists - more mailing lists