On Thu, Oct 3, 2024 at 12:33 PM Taehee Yoo <ap420073@xxxxxxxxx> wrote: > > On Fri, Oct 4, 2024 at 3:25 AM Mina Almasry <almasrymina@xxxxxxxxxx> wrote: > > > > On Thu, Oct 3, 2024 at 9:07 AM Taehee Yoo <ap420073@xxxxxxxxx> wrote: > > > > > > The tcp-data-split-thresh option configures the threshold value of > > > the tcp-data-split. > > > If a received packet size is larger than this threshold value, a packet > > > will be split into header and payload. > > > > Why do you need this? devmem TCP will always not work with unsplit > > packets. Seems like you always want to set thresh to 0 to support > > something like devmem TCP. > > > > Why would the user ever want to configure this? I can't think of a > > scenario where the user wouldn't want packets under X bytes to be > > unsplit. > > I totally understand what you mean, > Yes, tcp-data-split is zerocopy friendly option but as far as I know, > this option is not only for the zerocopy usecase. > So, If users enable tcp-data-split, they would assume threshold is 0. > But there are already NICs that have been supporting tcp-data-split > enabled by default. > bnxt_en's default value is 256bytes. > If we just assume the tcp-data-split-threshold to 0 for all cases, > it would change the default behavior of bnxt_en driver(maybe other drivers too) > for the not zerocopy case. > Jakub pointed out the generic case, not only for zerocopy usecase > in the v1 and I agree with that opinion. > https://lore.kernel.org/netdev/20240906183844.2e8226f3@xxxxxxxxxx/ I see, thanks. The ability to tune the threshold to save some pcie bandwidth is interesting. Not sure how much it would matter in practice. I guess if you're receiving _lots_ of small packets then it could be critical. Sounds good then, please consider adding Jakub's reasoning for why tuning this could be valuable to the commit message for future userspace readers that wonder why to set this. -- Thanks, Mina
