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: Sun, 20 Nov 2022 10:48:33 -0700 From: "Subash Abhinov Kasiviswanathan (KS)" <quic_subashab@...cinc.com> To: Daniele Palmas <dnlplm@...il.com>, Bjørn Mork <bjorn@...k.no> CC: Alexander Lobakin <alexandr.lobakin@...el.com>, David Miller <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Eric Dumazet <edumazet@...gle.com>, Sean Tranchetti <quic_stranche@...cinc.com>, Jonathan Corbet <corbet@....net>, "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>, <netdev@...r.kernel.org> Subject: Re: [PATCH net-next 2/3] net: qualcomm: rmnet: add tx packets aggregation On 11/20/2022 2:52 AM, Daniele Palmas wrote: > Il giorno dom 20 nov 2022 alle ore 10:39 Bjørn Mork <bjorn@...k.no> ha scritto: >> >> Daniele Palmas <dnlplm@...il.com> writes: >> >>> Ok, so rmnet would only take care of qmap rx packets deaggregation and >>> qmi_wwan of the tx aggregation. >>> >>> At a conceptual level, implementing tx aggregation in qmi_wwan for >>> passthrough mode could make sense, since the tx aggregation parameters >>> belong to the physical device and are shared among the virtual rmnet >>> netdevices, which can't have different aggr configurations if they >>> belong to the same physical device. >>> >>> Bjørn, would this approach be ok for you? >> >> Sounds good to me, if this can be done within the userspace API >> restrictions we've been through. >> >> I assume it's possible to make this Just Work(tm) in qmi_wwan >> passthrough mode? I do not think we want any solution where the user >> will have to configure both qmi_wwan and rmnet to make things work >> properly. >> > > Yes, I think so: the ethtool configurations would apply to the > qmi_wwan netdevice so that nothing should be done on the rmnet side. > > Regards, > Daniele My only concern against this option is that we would now need to end up implementing the same tx aggregation logic in the other physical device drivers - mhi_netdev & ipa. Keeping this tx aggregation logic in rmnet allows you to leverage it across all these various physical devices.
Powered by blists - more mailing lists