Re: [dpdk-dev] [PATCH v2] example/ipv4_multicast: fix app hanging when using clone

["Ananyev, Konstantin" <konstantin.ananyev@intel.com>]

> -----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