From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Olivier Matz
Sent: Friday, 30 July 2021 17.15

Hi,

On Fri, Jul 30, 2021 at 04:54:05PM +0200, Thomas Monjalon wrote:

quoted

30/07/2021 16:35, Morten Brørup:

quoted

quoted

From: Olivier Matz [mailto:olivier.matz@6wind.com]
Sent: Friday, 30 July 2021 14.37

Hi Thomas,

On Sat, Jul 24, 2021 at 10:47:34AM +0200, Thomas Monjalon wrote:

quoted

What's the follow-up for this patch?

Unfortunatly, I still don't have the time to work on this topic

yet.

quoted

quoted

quoted

In my initial tests, in our lab, I didn't notice any performance
regression, but Ali has seen an impact (0.5M PPS, but I don't

know how

quoted

quoted

quoted

much in percent).

quoted

19/01/2021 15:04, Slava Ovsiienko:

quoted

Hi, All

Could we postpose this patch at least to rc2? We would like

to

quoted

quoted

quoted

conduct more investigations?

quoted

quoted

With best regards, Slava

From: Olivier Matz <redacted>

quoted

On Mon, Jan 18, 2021 at 05:52:32PM +0000, Ali Alnubani

wrote:

quoted

quoted

quoted

quoted

quoted

quoted

quoted

Hi,
(Sorry had to resend this to some recipients due to mail

server

quoted

quoted

quoted

problems).

quoted

quoted

quoted

quoted

Just confirming that I can still reproduce the regression

with

quoted

quoted

quoted

single core and

quoted

quoted

quoted

64B frames on other servers.

Many thanks for the feedback. Can you please detail what is

the

quoted

quoted

quoted

amount of

quoted

quoted

quoted

performance loss in percent, and confirm the test case? (I

suppose it is

quoted

quoted

quoted

testpmd io forward).

Unfortunatly, I won't be able to spend a lot of time on

this soon

quoted

quoted

quoted

(sorry for

quoted

quoted

quoted

that). So I see at least these 2 options:

- postpone the patch again, until I can find more time to

analyze

quoted

quoted

quoted

quoted

quoted

quoted

  and optimize
- apply the patch if the performance loss is acceptable

compared

quoted

quoted

quoted

to

quoted

quoted

quoted

  the added value of fixing a bug

[...]

Statu quo...

Olivier

The decision should be simple:

Does the DPDK project support segmented packets?
If yes, then apply the patch to fix the bug!

If anyone seriously cares about the regression it introduces,

optimization patches are welcome later. We shouldn't wait for it.

quoted

You're right, but the regression is flagged to a 4-years old patch,
that's why I don't consider it as urgent.

quoted

If the patch is not applied, the documentation must be updated to

mention that we are releasing DPDK with a known bug: that segmented
packets are handled incorrectly in the scenario described in this
patch.

quoted

Yes, would be good to document the known issue,
no matter how old it is.

The problem description could be something like this:

  It is expected that free mbufs have their field m->nb_seg set to 1,
so
  that when it is allocated, the user does not need to set its
  value. The mbuf free functions are responsible of resetting this
field
  to 1 before returning the mbuf to the pool.

  When a multi-segment mbuf is freed, the m->nb_seg field is not reset
  to 1 for the last segment of the chain. On next allocation of this
  segment, if the field is not explicitly reset by the user, an invalid
  mbuf can be created, and can cause an undefined behavior.

And it needs to be put somewhere very prominent if we expect the users to read it.

Would adding an RTE_VERIFY() - instead of fixing the bug - cause a regression? If not, then any affected user will know what went wrong and where. This would still be an improvement, if the bugfix patch cannot be applied.

quoted

quoted

Generally, there could be some performance to gain by not

supporting segmented packets at all, as a compile time option. But that
is a different discussion.

quoted

quoted

-Morten