DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH RFC] mbuf: Adjust TX flags to start at bit 32
Date: Wed, 1 Oct 2014 09:47:21 +0100	[thread overview]
Message-ID: <20141001084721.GD1204@BRICHA3-MOBL> (raw)
In-Reply-To: <20140930170632.GJ2193@hmsreliant.think-freely.org>

On Tue, Sep 30, 2014 at 01:06:32PM -0400, Neil Horman wrote:
> On Tue, Sep 30, 2014 at 04:26:02PM +0100, Bruce Richardson wrote:
> > This patch takes the existing TX flags defined for the mbuf and shifts
> > each uniquely defined one left so that additional RX flags can be
> > defined without having RX and TX flags mixed together.
> > 
> > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> > ---
> >  lib/librte_mbuf/rte_mbuf.h | 26 +++++++++++++-------------
> >  1 file changed, 13 insertions(+), 13 deletions(-)
> > 
> > diff --git a/lib/librte_mbuf/rte_mbuf.h b/lib/librte_mbuf/rte_mbuf.h
> > index 1c6e115..c9fc4ec 100644
> > --- a/lib/librte_mbuf/rte_mbuf.h
> > +++ b/lib/librte_mbuf/rte_mbuf.h
> > @@ -86,26 +86,26 @@ extern "C" {
> >  #define PKT_RX_IEEE1588_PTP  0x0200 /**< RX IEEE1588 L2 Ethernet PT Packet. */
> >  #define PKT_RX_IEEE1588_TMST 0x0400 /**< RX IEEE1588 L2/L4 timestamped packet.*/
> >  
> > -#define PKT_TX_VLAN_PKT      0x0800 /**< TX packet is a 802.1q VLAN packet. */
> > -#define PKT_TX_IP_CKSUM      0x1000 /**< IP cksum of TX pkt. computed by NIC. */
> > -#define PKT_TX_IPV4_CSUM     0x1000 /**< Alias of PKT_TX_IP_CKSUM. */
> > -#define PKT_TX_IPV4          PKT_RX_IPV4_HDR /**< IPv4 with no IP checksum offload. */
> > -#define PKT_TX_IPV6          PKT_RX_IPV6_HDR /**< IPv6 packet */
> > +#define PKT_TX_VLAN_PKT  (0x0001 << 32) /**< TX packet is a 802.1q VLAN packet. */
> > +#define PKT_TX_IP_CKSUM  (0x0002 << 32) /**< IP cksum of TX pkt. computed by NIC. */
> > +#define PKT_TX_IPV4_CSUM PKT_TX_IP_CKSUM /**< Alias of PKT_TX_IP_CKSUM. */
> > +#define PKT_TX_IPV4      PKT_RX_IPV4_HDR /**< IPv4 with no IP checksum offload. */
> > +#define PKT_TX_IPV6      PKT_RX_IPV6_HDR /**< IPv6 packet */
> >  
> >  /*
> > - * Bit 14~13 used for L4 packet type with checksum enabled.
> > + * Bit 35~34 used for L4 packet type with checksum enabled.
> >   *     00: Reserved
> >   *     01: TCP checksum
> >   *     10: SCTP checksum
> >   *     11: UDP checksum
> >   */
> > -#define PKT_TX_L4_MASK       0x6000 /**< Mask bits for L4 checksum offload request. */
> > -#define PKT_TX_L4_NO_CKSUM   0x0000 /**< Disable L4 cksum of TX pkt. */
> > -#define PKT_TX_TCP_CKSUM     0x2000 /**< TCP cksum of TX pkt. computed by NIC. */
> > -#define PKT_TX_SCTP_CKSUM    0x4000 /**< SCTP cksum of TX pkt. computed by NIC. */
> > -#define PKT_TX_UDP_CKSUM     0x6000 /**< UDP cksum of TX pkt. computed by NIC. */
> > -/* Bit 15 */
> > -#define PKT_TX_IEEE1588_TMST 0x8000 /**< TX IEEE1588 packet to timestamp. */
> > +#define PKT_TX_L4_NO_CKSUM   (0x0000 << 32) /**< Disable L4 cksum of TX pkt. */
> > +#define PKT_TX_TCP_CKSUM     (0x0004 << 32) /**< TCP cksum of TX pkt. computed by NIC. */
> > +#define PKT_TX_SCTP_CKSUM    (0x0008 << 32) /**< SCTP cksum of TX pkt. computed by NIC. */
> > +#define PKT_TX_UDP_CKSUM     (0x000C << 32) /**< UDP cksum of TX pkt. computed by NIC. */
> > +#define PKT_TX_L4_MASK       (0x000C << 32) /**< Mask for L4 cksum offload request. */
> > +/* Bit 36 */
> > +#define PKT_TX_IEEE1588_TMST (0x0010 << 32) /**< TX IEEE1588 packet to timestamp. */
> >  
> >  /* Use final bit of flags to indicate a control mbuf */
> >  #define CTRL_MBUF_FLAG       (1ULL << 63)
> > -- 
> > 1.9.3
> > 
> > 
> 
> I'm not opposed to the patch at all, but I would like to point out that this is
> the sort of change that breaks ABI very easily (which is fine right now given
> the mbuf changes already staged for the release, but still something to be aware
> of).  As such, are there advantages to this patch (other than the niceness of
> human readability)?
> 
> If we're going to reshuffle these flags now, it might be nice to start tx flags
> at the most significant bit and count back, and start rx flags at the least
> significant bit and count up.  That would ensure that we don't reserve flags for
> a direction without need.
> 
> Best
> Neil
>
Good idea, though currently the most significant bit is being used as a flag 
to indicate a control mbuf. My thinking is that we may potentially need 
other flags that are not just for RX or TX, and to have those at the end.  
However, given that that is likely to be the exception case, perhaps we 
could reserve the last byte for non-RX/TX flags and then implement the 
scheme you suggest. What do you think?

/Bruce 

  reply	other threads:[~2014-10-01  8:40 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-30 15:26 Bruce Richardson
2014-09-30 15:33 ` Bruce Richardson
2014-09-30 16:00   ` Wiles, Roger Keith
2014-09-30 16:03     ` Bruce Richardson
2014-09-30 17:06 ` Neil Horman
2014-10-01  8:47   ` Bruce Richardson [this message]
2014-10-01 11:14     ` Neil Horman

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=20141001084721.GD1204@BRICHA3-MOBL \
    --to=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=nhorman@tuxdriver.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).