DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Zhang, Helin" <helin.zhang@intel.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v2 2/2] mbuf: assign valid bit values for some RX and TX flags
Date: Tue, 9 Dec 2014 02:29:50 +0000	[thread overview]
Message-ID: <F35DEAC7BCE34641BA9FAC6BCA4A12E70A7CFA9B@SHSMSX104.ccr.corp.intel.com> (raw)
In-Reply-To: <2601191342CEEE43887BDE71AB977258213BDAC4@IRSMSX105.ger.corp.intel.com>



> -----Original Message-----
> From: Ananyev, Konstantin
> Sent: Monday, December 8, 2014 6:55 PM
> To: Zhang, Helin; dev@dpdk.org
> Cc: Cao, Waterman; Cao, Min; Wu, Jingjing; Liu, Jijiang;
> olivier.matz@6wind.com
> Subject: RE: [PATCH v2 2/2] mbuf: assign valid bit values for some RX and TX
> flags
> 
> 
> 
> > -----Original Message-----
> > From: Zhang, Helin
> > Sent: Saturday, December 06, 2014 1:08 AM
> > To: Ananyev, Konstantin; dev@dpdk.org
> > Cc: Cao, Waterman; Cao, Min; Wu, Jingjing; Liu, Jijiang;
> > olivier.matz@6wind.com
> > Subject: RE: [PATCH v2 2/2] mbuf: assign valid bit values for some RX
> > and TX flags
> >
> >
> >
> > > -----Original Message-----
> > > From: Zhang, Helin
> > > Sent: Saturday, December 6, 2014 8:40 AM
> > > To: Ananyev, Konstantin; dev@dpdk.org
> > > Cc: Cao, Waterman; Cao, Min; Wu, Jingjing; Liu, Jijiang;
> > > olivier.matz@6wind.com
> > > Subject: RE: [PATCH v2 2/2] mbuf: assign valid bit values for some
> > > RX and TX flags
> > >
> > > OK. I will send out another patch according to your comments. Thanks a lot!
> > >
> > > Regards,
> > > Helin
> > >
> > > > -----Original Message-----
> > > > From: Ananyev, Konstantin
> > > > Sent: Friday, December 5, 2014 6:50 PM
> > > > To: Zhang, Helin; dev@dpdk.org
> > > > Cc: Cao, Waterman; Cao, Min; Wu, Jingjing; Liu, Jijiang;
> > > > olivier.matz@6wind.com
> > > > Subject: RE: [PATCH v2 2/2] mbuf: assign valid bit values for some
> > > > RX and TX flags
> > > >
> > > > Hi Helin,
> > > >
> > > > > -----Original Message-----
> > > > > From: Zhang, Helin
> > > > > Sent: Friday, December 05, 2014 1:46 AM
> > > > > To: dev@dpdk.org
> > > > > Cc: Cao, Waterman; Cao, Min; Wu, Jingjing; Liu, Jijiang;
> > > > > Ananyev, Konstantin; olivier.matz@6wind.com; Zhang, Helin
> > > > > Subject: [PATCH v2 2/2] mbuf: assign valid bit values for some
> > > > > RX and TX flags
> > > > >
> > > > > Before redefining mbuf structure, there was lack of free bits in
> > > > > 'ol_flags' (32 bits in total) for new RX or TX flags. So it
> > > > > tried to reuse existant bits as most as possible, or even
> > > > > assigning 0 to some of bit flags. After new mbuf structure
> > > > > defined, there are quite a lot of free bits. So those newly
> > > > > added bit flags should be assigned with correct and valid bit
> > > > > values, and getting their names should be enabled as well. Note
> > > > > that 'RECIP' should be removed, as nowhere will use it.
> > > > >
> > > > > Signed-off-by: Helin Zhang <helin.zhang@intel.com>
> > > > > ---
> > > > >  lib/librte_mbuf/rte_mbuf.c |  9 ++++-----
> > > > > lib/librte_mbuf/rte_mbuf.h
> > > > > | 19 +++++++++----------
> > > > >  2 files changed, 13 insertions(+), 15 deletions(-)
> > > > >
> > > > > v2 changes:
> > > > > * Removed error flag of 'ECIPE' processing only in mbuf. All other error
> flags
> > > > >   were added back.
> > > > > * Assigned error flags with correct and valid values, as their previous
> values
> > > > >   were invalid.
> > > > > * Enabled getting all error flag names.
> > > > >
> > > > > diff --git a/lib/librte_mbuf/rte_mbuf.c
> > > > > b/lib/librte_mbuf/rte_mbuf.c index 87c2963..3ce7c8d 100644
> > > > > --- a/lib/librte_mbuf/rte_mbuf.c
> > > > > +++ b/lib/librte_mbuf/rte_mbuf.c
> > > > > @@ -210,11 +210,10 @@ const char
> > > > > *rte_get_rx_ol_flag_name(uint64_t
> > > > mask)
> > > > >  	case PKT_RX_FDIR: return "PKT_RX_FDIR";
> > > > >  	case PKT_RX_L4_CKSUM_BAD: return "PKT_RX_L4_CKSUM_BAD";
> > > > >  	case PKT_RX_IP_CKSUM_BAD: return "PKT_RX_IP_CKSUM_BAD";
> > > > > -	/* case PKT_RX_EIP_CKSUM_BAD: return
> "PKT_RX_EIP_CKSUM_BAD"; */
> > > > > -	/* case PKT_RX_OVERSIZE: return "PKT_RX_OVERSIZE"; */
> > > > > -	/* case PKT_RX_HBUF_OVERFLOW: return
> "PKT_RX_HBUF_OVERFLOW";
> > > > */
> > > > > -	/* case PKT_RX_RECIP_ERR: return "PKT_RX_RECIP_ERR"; */
> > > > > -	/* case PKT_RX_MAC_ERR: return "PKT_RX_MAC_ERR"; */
> > > > > +	case PKT_RX_EIP_CKSUM_BAD: return "PKT_RX_EIP_CKSUM_BAD";
> > > > > +	case PKT_RX_OVERSIZE: return "PKT_RX_OVERSIZE";
> > > > > +	case PKT_RX_HBUF_OVERFLOW: return
> > > "PKT_RX_HBUF_OVERFLOW";
> > > > > +	case PKT_RX_MAC_ERR: return "PKT_RX_MAC_ERR";
> > > > >  	case PKT_RX_IPV4_HDR: return "PKT_RX_IPV4_HDR";
> > > > >  	case PKT_RX_IPV4_HDR_EXT: return "PKT_RX_IPV4_HDR_EXT";
> > > > >  	case PKT_RX_IPV6_HDR: return "PKT_RX_IPV6_HDR"; diff --git
> > > > > a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h index
> > > > > 2e5fce5..c9591c0 100644
> > > > > --- a/lib/librte_mbuf/rte_mbuf.h
> > > > > +++ b/lib/librte_mbuf/rte_mbuf.h
> > > > > @@ -84,11 +84,6 @@ extern "C" {
> > > > >  #define PKT_RX_FDIR          (1ULL << 2)  /**< RX packet with
> FDIR
> > > > match indicate. */
> > > > >  #define PKT_RX_L4_CKSUM_BAD  (1ULL << 3)  /**< L4 cksum of RX
> pkt.
> > > > is
> > > > > not OK. */  #define PKT_RX_IP_CKSUM_BAD  (1ULL << 4)  /**< IP
> > > > > cksum
> > > > of
> > > > > RX pkt. is not OK. */ -#define PKT_RX_EIP_CKSUM_BAD (0ULL << 0)
> > > > > /**<
> > > > External IP header checksum error. */
> > > > > -#define PKT_RX_OVERSIZE      (0ULL << 0)  /**< Num of desc of an
> RX
> > > > pkt oversize. */
> > > > > -#define PKT_RX_HBUF_OVERFLOW (0ULL << 0)  /**< Header buffer
> > > > overflow. */
> > > > > -#define PKT_RX_RECIP_ERR     (0ULL << 0)  /**< Hardware
> processing
> > > > error. */
> > > > > -#define PKT_RX_MAC_ERR       (0ULL << 0)  /**< MAC error. */
> > > > >  #define PKT_RX_IPV4_HDR      (1ULL << 5)  /**< RX packet with
> IPv4
> > > > header. */
> > > > >  #define PKT_RX_IPV4_HDR_EXT  (1ULL << 6)  /**< RX packet with
> > > > extended IPv4 header. */
> > > > >  #define PKT_RX_IPV6_HDR      (1ULL << 7)  /**< RX packet with
> IPv6
> > > > header. */
> > > > > @@ -99,6 +94,10 @@ extern "C" {
> > > > >  #define PKT_RX_TUNNEL_IPV6_HDR (1ULL << 12) /**< RX tunnel
> > > > > packet
> > > > with IPv6 header. */
> > > > >  #define PKT_RX_FDIR_ID       (1ULL << 13) /**< FD id reported if
> FDIR
> > > > match. */
> > > > >  #define PKT_RX_FDIR_FLX      (1ULL << 14) /**< Flexible bytes
> > > reported
> > > > if FDIR match. */
> > > > > +#define PKT_RX_EIP_CKSUM_BAD (1ULL << 15)  /**< External IP
> > > > > +header
> > > > checksum error. */
> > > > > +#define PKT_RX_OVERSIZE      (1ULL << 16)  /**< Num of desc of
> an
> > > RX
> > > > pkt oversize. */
> > > > > +#define PKT_RX_HBUF_OVERFLOW (1ULL << 17)  /**< Header buffer
> > > > overflow. */
> > > > > +#define PKT_RX_MAC_ERR       (1ULL << 18)  /**< MAC error. */
> > > > >  /* add new RX flags here */
> > > >
> > > > I still think there is no point to have several flags to indicate
> > > > HW error for the packet.
> > > > As I suggested before we can collapse 3 of them (OVERSIZE,
> > > > HBUF_OVERFLOW,
> > > > MAC_ERR) into one.
> > > > As I remember, Oliver even suggested to drop such packets.
> > > > As was said above - if is not a whole packet SW can't do much with it
> anyway.
> > > > The only thing such bad packets can probably be used for - some
> > > > sort of debugging.
> > > > So we probably can combine both things:
> > > > - in normal operation just drop such packet
> > > > - if PMD_DEBUG_RX is enabled, then write a log record, set
> > > > RX_HW_ERR and deliver a packet to the upper layer.
> > I still do not want to drop the bad packet here, as it may affect vector
> processing.
> > At least it should be investigated how much impact on vector RX. I
> > prefer to let up-layer software do that.
> 
> But right now, i40e doesn't have any vector RX support.
> You probably meant implications with scatter RX, no?
I was thinking we may need to add the similar things in igb and ixgbe (possibly vector).

> Another thing - if you HW can't receive packets normally, then something really
> wrong is going on.
> In such situation, you probably wouldn't worry about your RX performance
That may need an if() for each received packets without any error, though might
not affect performance number.

> anyway :) But I suppose it is a good first step, let's just collapse 3 error flags
> into one for now.
> Then  we can decide should we drop such packets or not.
> Konstantin
Agree to think more on this point!

> 
> >
> > > >
> > > > >
> > > > >  /* add new TX flags here */
> > > > > @@ -141,13 +140,13 @@ extern "C" {
> > > > >  #define PKT_TX_IP_CKSUM      (1ULL << 54) /**< IP cksum of TX
> pkt.
> > > > computed by NIC. */
> > > > >  #define PKT_TX_IPV4_CSUM     PKT_TX_IP_CKSUM /**< Alias of
> > > > PKT_TX_IP_CKSUM. */
> > > > >
> > > > > -/** Tell the NIC it's an IPv4 packet. Required for L4 checksum
> > > > > offload or
> > > TSO.
> > > > */
> > > > > -#define PKT_TX_IPV4          PKT_RX_IPV4_HDR
> > > > > +/** Tell the NIC it's an IPv4 packet. */
> > > > > +#define PKT_TX_IPV4          (1ULL << 55) /**< TX packet is a IPV4
> > > > packet. */
> > > > >
> > > > > -/** Tell the NIC it's an IPv6 packet. Required for L4 checksum
> > > > > offload or
> > > TSO.
> > > > */
> > > > > -#define PKT_TX_IPV6          PKT_RX_IPV6_HDR
> > > > > +/** Tell the NIC it's an IPv6 packet. */
> > > > > +#define PKT_TX_IPV6          (1ULL << 56) /**< TX packet is a IPV6
> > > > packet. */
> > > > >
> > > > > -#define PKT_TX_VLAN_PKT      (1ULL << 55) /**< TX packet is a
> 802.1q
> > > > VLAN packet. */
> > > > > +#define PKT_TX_VLAN_PKT      (1ULL << 57) /**< TX packet is a
> VLAN
> > > > packet. */
> > > >
> > > > I don't think these changes should be part of that patch.
> > > > They violate another patch that Frank sent before.
> > > >
> > > > Konstantin
> > > >
> > > > >
> > > > >  /* Use final bit of flags to indicate a control mbuf */
> > > > >  #define CTRL_MBUF_FLAG       (1ULL << 63) /**< Mbuf contains
> > > control
> > > > data */
> > > > > --
> > > > > 1.9.3

Regards,
Helin

  reply	other threads:[~2014-12-09  2:30 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-26  6:07 [dpdk-dev] [PATCH] i40e: Use one bit flag for all hardware detected RX packet errors Helin Zhang
2014-11-26 10:49 ` Ananyev, Konstantin
2014-11-26 11:22   ` Olivier MATZ
2014-11-26 13:38     ` Ananyev, Konstantin
2014-11-26 14:12       ` Olivier MATZ
2014-11-28  8:07         ` Zhang, Helin
2014-11-28  8:47           ` Olivier MATZ
2014-12-01  1:57             ` Zhang, Helin
2014-12-01  9:58               ` Olivier MATZ
2014-12-02  7:25                 ` Zhang, Helin
2014-12-05  1:46 ` [dpdk-dev] [PATCH v2 0/2] fix of enabling all newly added error flags Helin Zhang
2014-12-05  1:46   ` [dpdk-dev] [PATCH v2 1/2] i40e: remove checking rxd flag which is not public Helin Zhang
2014-12-05  1:46   ` [dpdk-dev] [PATCH v2 2/2] mbuf: assign valid bit values for some RX and TX flags Helin Zhang
2014-12-05 10:49     ` Ananyev, Konstantin
2014-12-06  0:42       ` Zhang, Helin
2014-12-06  1:07       ` Zhang, Helin
2014-12-08 10:55         ` Ananyev, Konstantin
2014-12-09  2:29           ` Zhang, Helin [this message]
2014-12-06  1:33   ` [dpdk-dev] [PATCH v3] mbuf: fix of enabling all newly added RX error flags Helin Zhang
2014-12-08 10:44     ` Ananyev, Konstantin
2014-12-09  2:23       ` Zhang, Helin
2014-12-08 10:50     ` Thomas Monjalon
2014-12-09  2:14       ` Zhang, Helin
2014-12-09  6:22         ` Thomas Monjalon
2014-12-10  8:55     ` [dpdk-dev] [PATCH v4] " Helin Zhang
2014-12-10  9:35       ` Thomas Monjalon
2014-12-10 13:50         ` Zhang, Helin
2014-12-10 15:26           ` Thomas Monjalon
2014-12-10 22:29             ` Zhang, Helin
2014-12-11 11:16               ` Olivier MATZ
2014-12-12  1:27                 ` Zhang, Helin

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=F35DEAC7BCE34641BA9FAC6BCA4A12E70A7CFA9B@SHSMSX104.ccr.corp.intel.com \
    --to=helin.zhang@intel.com \
    --cc=dev@dpdk.org \
    --cc=konstantin.ananyev@intel.com \
    /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).