> -----Original Message----- > From: users <[email protected]> On Behalf Of Stephen Hemminger > Sent: Thursday, June 10, 2021 5:29 PM > To: Alan Arondel <[email protected]> > Cc: [email protected] > Subject: Re: [dpdk-users] Tx burst and ordered packets > > Are you using RSS on the receiver. > Packets sent in one burst should go out in order (if not it is a Intel > driver bug)
[Sidenote: its best practice to reply inline when answering questions on mailing lists.] > On Mon, Jun 7, 2021 at 3:09 PM Alan Arondel <[email protected]> wrote: > > > Hello everyone, > > > > I just wanted to know if a burst of packets using rte_eth_tx_burst are > > send in the same order of the parameter struct rte_mbuf ** tx_pkts ? > > I tried the skeleton sample which use this api and can confirm that the > > received packets are not in the right order. Probably I'm doing something > > wrong somewhere. Stephen is correct in that the rte_mbuf **tx_pkts order is the order packets should be sent on the wire. Indeed if they are not, it is a driver bug, and should be fixed. Before we jump to that conclusion, can I suggest we look at how packet ordering is being measured? Keep in mind packets could be dropped along the way, so if we count (N) and (N+1) on the next packet, and then validate ordering by ensuring the received packets are exactly (N, N+1), then a drop would suggest re-ordering issues... > > I use the driver net_i40e. > > Dpdk version 20.11.1 > > Compilation withtout any specifique parameters (meson > > configure/ninja/ninja install) > > I cannot find any discussion or information about this. I expect that would work correctly. > > Thank you for any reply. > > > > Regards, > > Alan. Regards, -Harry PS: Please try to avoid sending the below to public mailing lists like DPDK: > > This message, including attachments, is CONFIDENTIAL. It may also be > > privileged or otherwise protected by law. If you received this email by > > mistake please let us know by reply and then delete it from your system; > > you should not copy it or disclose its contents to anyone. All messages > > sent to and from Enea may be monitored to ensure compliance with internal > > policies and to protect our business. Emails are not secure and cannot be > > guaranteed to be error free as they can be intercepted, amended, lost or > > destroyed, or contain viruses. The sender therefore does not accept > > liability for any errors or omissions in the contents of this message, > > which arise as a result of email transmission. Anyone who communicates with > > us by email accepts these risks. > >
