DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Wang, Dong1" <dong1.wang@intel.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
	"Lipiec, Herakliusz" <herakliusz.lipiec@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Cc: "thomas@monjalon.net" <thomas@monjalon.net>,
	"Burakov, Anatoly" <anatoly.burakov@intel.com>,
	"stable@dpdk.org" <stable@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v2] example/ipv4_multicast: fix app hanging when using clone
Date: Wed, 14 Nov 2018 11:32:55 +0000	[thread overview]
Message-ID: <3E2E5017C928014B90FD7864A64F0B5514F75036@SHSMSX103.ccr.corp.intel.com> (raw)
In-Reply-To: <2601191342CEEE43887BDE71AB977258010CEB795B@IRSMSX106.ger.corp.intel.com>

OK, understand now.

Thanks,
Dong

-----Original Message-----
From: Ananyev, Konstantin 
Sent: Wednesday, November 14, 2018 19:19
To: Wang, Dong1 <dong1.wang@intel.com>; Lipiec, Herakliusz <herakliusz.lipiec@intel.com>; dev@dpdk.org
Cc: thomas@monjalon.net; Burakov, Anatoly <anatoly.burakov@intel.com>; stable@dpdk.org
Subject: RE: [PATCH v2] example/ipv4_multicast: fix app hanging when using clone



> -----Original Message-----
> From: Wang, Dong1
> Sent: Wednesday, November 14, 2018 11:06 AM
> To: Ananyev, Konstantin <konstantin.ananyev@intel.com>; Lipiec, 
> Herakliusz <herakliusz.lipiec@intel.com>; dev@dpdk.org
> Cc: thomas@monjalon.net; Burakov, Anatoly <anatoly.burakov@intel.com>; 
> stable@dpdk.org
> Subject: RE: [PATCH v2] example/ipv4_multicast: fix app hanging when 
> using clone
> 
> Hi Konstantin & Herakliusz,
> 
> In mcast_out_pkt(), new header added and to be the first segment. Driver will check first segment's ol_flags when sending mbuf.

It will check for *TX* flags.
TX flags are not set in cloned mbuf (only RX ones).

> So why new first segment didn't inherit old one's ol_flags? 

Because they are RX flags and they don't' really belong to new packet we are going to send.
Also, as that bug shows it is error prone.

> This function already copied other mbuf fields from old one.

And from my perspective it is not needed and better be removed.
Though it is a subject of different patch probably.

> 
> Since this is an example and reference code, hope developer can reuse 
> it smoothly. If they didn't notice ol_flags not be copied because ol_flags is not changed in this example, they may take some time to debug their application.

For that scenario it is not needed.
Surely when user linking two packets manually (as we are doing here) it is his responsibility to update the mbuf fileds properly.
I think this is obvious thing and probably already mentioned in the docs.
Konstantin

> 
> This is a tiny change to the patch, I hope it cloud be done.
> 
> Thanks,
> Dong
> 
> -----Original Message-----
> From: Ananyev, Konstantin
> Sent: Wednesday, November 14, 2018 18:18
> To: Wang, Dong1 <dong1.wang@intel.com>; Lipiec, Herakliusz 
> <herakliusz.lipiec@intel.com>; dev@dpdk.org
> Cc: thomas@monjalon.net; Burakov, Anatoly <anatoly.burakov@intel.com>; 
> stable@dpdk.org
> Subject: RE: [PATCH v2] example/ipv4_multicast: fix app hanging when 
> using clone
> 
> 
> >
> > Hi Konstantin,
> >
> > In this example, no flags be set by user, so no need to copy flags from original  mbuf.
> 
> Then why to bother?
> 
> > I'm thinking about some DPDK developers may create their own 
> > application based on this example,  they add some flags before packet be cloned.
> 
> Hmm you receive a packet change l2 header and transmit it.
> What flags you might need to copy from original header considering that only RX flags would be set at present moment?
> If you let say want to insert vlan tag (or so), then you'll have to set new TX flags.
> Again, for timestamp you'll need to copy the timestamp value too, which we don't support in that example.
> Konstantin
> 
> >
> > Regards,
> > Dong
> >
> > -----Original Message-----
> > From: Ananyev, Konstantin
> > Sent: Wednesday, November 14, 2018 17:03
> > To: Wang, Dong1 <dong1.wang@intel.com>; Lipiec, Herakliusz 
> > <herakliusz.lipiec@intel.com>; dev@dpdk.org
> > Cc: thomas@monjalon.net; Burakov, Anatoly 
> > <anatoly.burakov@intel.com>; stable@dpdk.org
> > Subject: RE: [PATCH v2] example/ipv4_multicast: fix app hanging when 
> > using clone
> >
> > Hi Dong,
> >
> > > Hi Herakliusz,
> > >
> > > Since pkt->ol_flags might set some other bits except 
> > > IND_ATTACHED_MBUF, how about set its value to original 
> > > pkt->ol_flag
> >
> > It could be done, but not sure what is the point?
> > Which flags you think we need to copy from cloned mbuf (segment #2) to new header?
> > Konstantin
> >
> > >
> > > Regards,
> > > Dong
> > >
> > > -----Original Message-----
> > > From: Lipiec, Herakliusz
> > > Sent: Tuesday, November 13, 2018 19:49
> > > To: dev@dpdk.org
> > > Cc: Ananyev, Konstantin <konstantin.ananyev@intel.com>; Wang, 
> > > Dong1 <dong1.wang@intel.com>; thomas@monjalon.net; Burakov, 
> > > Anatoly <anatoly.burakov@intel.com>; Lipiec, Herakliusz 
> > > <herakliusz.lipiec@intel.com>; stable@dpdk.org
> > > Subject: [PATCH v2] example/ipv4_multicast: fix app hanging when 
> > > using clone
> > >
> > > The ipv4_multicast sample application was dropping packets when 
> > > using mbuf clone. When creating an L2 header and copying metadata 
> > > from the source packet, the ol_flags were also copied along with 
> > > all the other metadata. Because the cloned packet had 
> > > IND_ATTACHED_MBUF
> > flag set in its ol_flags, this caused the packets to never be freed when using rte_pktmbuf_free.
> > > Since copying ol_flags from the cloned packet is not necessary in the first place, just don't do it.
> > >
> > > Fixes: af75078fece3 ("first public release")
> > > CC: stable@dpdk.org
> > >
> > > Reported-by: Wang Dong <dong1.wang@intel.com>
> > > Signed-off-by: Herakliusz Lipiec <herakliusz.lipiec@intel.com>
> > > ---
> > >  doc/guides/sample_app_ug/ipv4_multicast.rst | 1 -
> > >  examples/ipv4_multicast/main.c              | 2 --
> > >  2 files changed, 3 deletions(-)
> > >
> > > diff --git a/doc/guides/sample_app_ug/ipv4_multicast.rst
> > > b/doc/guides/sample_app_ug/ipv4_multicast.rst
> > > index ce1474ec7..f6efa7f6f 100644
> > > --- a/doc/guides/sample_app_ug/ipv4_multicast.rst
> > > +++ b/doc/guides/sample_app_ug/ipv4_multicast.rst
> > > @@ -319,7 +319,6 @@ It is the mcast_out_pkt() function that performs the packet duplication (either
> > >          hdr->pkt.in_port = pkt->pkt.in_port;
> > >          hdr->pkt.vlan_macip = pkt->pkt.vlan_macip;
> > >          hdr->pkt.hash = pkt->pkt.hash;
> > > -        hdr->ol_flags = pkt->ol_flags;
> > >          rte_mbuf_sanity_check(hdr, RTE_MBUF_PKT, 1);
> > >
> > >          return hdr;
> > > diff --git a/examples/ipv4_multicast/main.c 
> > > b/examples/ipv4_multicast/main.c index 4073a4907..428ca4694 100644
> > > --- a/examples/ipv4_multicast/main.c
> > > +++ b/examples/ipv4_multicast/main.c
> > > @@ -266,8 +266,6 @@ mcast_out_pkt(struct rte_mbuf *pkt, int use_clone)
> > >  	hdr->tx_offload = pkt->tx_offload;
> > >  	hdr->hash = pkt->hash;
> > >
> > > -	hdr->ol_flags = pkt->ol_flags;
> > > -
> > >  	__rte_mbuf_sanity_check(hdr, 1);
> > >  	return hdr;
> > >  }
> > > --
> > > 2.17.1

  reply	other threads:[~2018-11-14 11:33 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-12 20:46 [dpdk-dev] [PATCH] " Herakliusz Lipiec
2018-11-12 22:44 ` Ananyev, Konstantin
2018-11-13  9:25 ` Thomas Monjalon
2018-11-13  9:47   ` Ananyev, Konstantin
2018-11-13 10:21 ` Burakov, Anatoly
2018-11-13 10:28   ` Ananyev, Konstantin
2018-11-13 11:49 ` [dpdk-dev] [PATCH v2] " Herakliusz Lipiec
2018-11-13 11:51   ` Ananyev, Konstantin
2018-11-14 11:33     ` Wang, Dong1
2018-11-18 21:56       ` [dpdk-dev] [dpdk-stable] " Thomas Monjalon
2018-11-14  2:28   ` [dpdk-dev] " Wang, Dong1
2018-11-14  9:02     ` Ananyev, Konstantin
2018-11-14 10:09       ` Wang, Dong1
2018-11-14 10:17         ` Ananyev, Konstantin
2018-11-14 11:06           ` Wang, Dong1
2018-11-14 11:19             ` Ananyev, Konstantin
2018-11-14 11:32               ` Wang, Dong1 [this message]
2018-11-20  5:40               ` Zhao1, Wei
2018-11-20  9:52                 ` Ananyev, Konstantin
2018-11-14 10:21         ` Lipiec, Herakliusz

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=3E2E5017C928014B90FD7864A64F0B5514F75036@SHSMSX103.ccr.corp.intel.com \
    --to=dong1.wang@intel.com \
    --cc=anatoly.burakov@intel.com \
    --cc=dev@dpdk.org \
    --cc=herakliusz.lipiec@intel.com \
    --cc=konstantin.ananyev@intel.com \
    --cc=stable@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).