From: Ivan Malov <ivan.malov@arknetworks.am>
To: "Morten Brørup" <mb@smartsharesystems.com>
Cc: dev@dpdk.org, techboard@dpdk.org, stephen@networkplumber.org,
Thomas Monjalon <thomas@monjalon.net>,
Andrew Rybchenko <andrew.rybchenko@oktetlabs.ru>,
Patrick Robb <probb@iol.unh.edu>
Subject: Re: Use of TX offload flags MBUF_FAST_FREE and MULTI_SEGS
Date: Mon, 6 Oct 2025 18:59:33 +0400 (+04) [thread overview]
Message-ID: <8ce42638-6d69-8ae5-867f-8d803214aa13@arknetworks.am> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35F654A3@smartserver.smartshare.dk>
[-- Attachment #1: Type: text/plain, Size: 1972 bytes --]
Hi Morten,
I apologise for my original notice about the co-existence of these flags.
Were it not for my notice, things wouldn't have gone wrong, I take it.
Thank you.
On Mon, 6 Oct 2025, Morten Brørup wrote:
>> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
>> Sent: Friday, 3 October 2025 11.18
>> Subject: Minutes of techboard meeting, 2025-10-01
>
>> * Use of FAST_FREE and multi-buffer/scattered mbuf flags
>> - The flags for enabling fast-free and supporting multi-mbuf packets
>> are
>> now documented incompatible
>> - Previously they were not defined as incompatible, but that seems to
>> have been assumed for some usages.
>> - Techboard discussed how best to resolve this incompatibility with
>> regards to:
>> - ensuring correctness
>> - avoiding major churn to DPDK code
>> - avoiding churn to end-user code
>> - Options discussed:
>> 1 change definition back to not have the settings incompatible:
>> this
>> necessitates checking drivers for correctness
>> 2 keep as explicitly incompatible and report error if both
>> specified:
>> this could break end-user apps, and requires changes to example
>> apps
>> 3 drop the fast-free flag if multi-segment mbufs are also
>> specified:
>> "hides" the issue, but probably minimises changes. Would need to
>> decide whether the dropping of flag done in drivers vs ethdev
>> level.
>> Pros and cons to both options. Needs clear documenting.
>> - No firm decision reached, will discuss more over email.
>
> IMO, the patch [1] making MBUF_FAST_FREE and MULTI_SEGS explicitly incompatible should be reverted, at least for RC1.
> That will take the project back to the state it was in before we started this discussion.
> And all the examples broken by the patch (because they use both TX offloads) will not need fixing.
>
> [1]: https://patchwork.dpdk.org/project/dpdk/patch/20250803194218.683318-3-mb@smartsharesystems.com/
>
>
prev parent reply other threads:[~2025-10-06 14:59 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-03 9:17 Minutes of techboard meeting, 2025-10-01 Bruce Richardson
2025-10-06 14:40 ` Morten Brørup
2025-10-07 7:58 ` Stephen Hemminger
2025-10-08 12:36 ` Use of TX offload flags MBUF_FAST_FREE and MULTI_SEGS Morten Brørup
2025-10-06 14:51 ` Morten Brørup
2025-10-06 14:59 ` Ivan Malov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8ce42638-6d69-8ae5-867f-8d803214aa13@arknetworks.am \
--to=ivan.malov@arknetworks.am \
--cc=andrew.rybchenko@oktetlabs.ru \
--cc=dev@dpdk.org \
--cc=mb@smartsharesystems.com \
--cc=probb@iol.unh.edu \
--cc=stephen@networkplumber.org \
--cc=techboard@dpdk.org \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).