DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Morten Brørup" <mb@smartsharesystems.com>
To: <dev@dpdk.org>
Cc: "Olivier Matz" <olivier.matz@6wind.com>
Subject: [dpdk-dev] rte_ether_addr_copy() strange comment
Date: Thu, 25 Jun 2020 17:45:58 +0200	[thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35C610C4@smartserver.smartshare.dk> (raw)

The function rte_ether_addr_copy() checks for __INTEL_COMPILER and has a comment about "a strange gcc warning". It says:

static inline void rte_ether_addr_copy(const struct rte_ether_addr *ea_from,
				   struct rte_ether_addr *ea_to)
{
#ifdef __INTEL_COMPILER
	uint16_t *from_words = (uint16_t *)(ea_from->addr_bytes);
	uint16_t *to_words   = (uint16_t *)(ea_to->addr_bytes);

	to_words[0] = from_words[0];
	to_words[1] = from_words[1];
	to_words[2] = from_words[2];
#else
	/*
	 * Use the common way, because of a strange gcc warning.
	 */
	*ea_to = *ea_from;
#endif
}

I can see that from_words discards the const qualifier. Is that the "strange" gcc warning the comment is referring to?

This goes back to before the first public release of DPDK in 2013, ref. https://git.dpdk.org/dpdk/log/lib/librte_ether/rte_ether.h


It should be fixed as follows:

-	uint16_t *from_words = (uint16_t *)(ea_from->addr_bytes);
-	uint16_t *to_words   = (uint16_t *)(ea_to->addr_bytes);
+	const uint16_t *from_words = (const uint16_t *)ea_from;
+	uint16_t       *to_words   = (uint16_t *)ea_to;

And the consequential question: Is copying the three shorts faster than copying the struct? In other words: Should we get rid of the #ifdef and use the first method only?

PS: I will provide a patch which improves rte_is_broadcast_ether_addr() too. The magic formula here is: return (w[0] & w[1] & w[2]) == 0xFFFF;


Med venlig hilsen / kind regards
- Morten Brørup



             reply	other threads:[~2020-06-25 15:46 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-25 15:45 Morten Brørup [this message]
2020-06-26 12:08 ` Ferruh Yigit
2020-06-26 12:34   ` Morten Brørup
2020-06-26 14:37     ` Jerin Jacob
2020-06-26 12:41   ` Van Haaren, Harry
2020-06-26 15:54     ` Ferruh Yigit
2020-06-26 17:28       ` Van Haaren, Harry
2020-06-26 18:04         ` Stephen Hemminger

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=98CBD80474FA8B44BF855DF32C47DC35C610C4@smartserver.smartshare.dk \
    --to=mb@smartsharesystems.com \
    --cc=dev@dpdk.org \
    --cc=olivier.matz@6wind.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).