From: Neil Horman <nhorman@tuxdriver.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
Cc: "Nélio Laranjeiro" <nelio.laranjeiro@6wind.com>,
"Morten Brørup" <mb@smartsharesystems.com>,
"Wiles, Keith" <keith.wiles@intel.com>,
"Richardson, Bruce" <bruce.richardson@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>,
"Olivier Matz" <olivier.matz@6wind.com>,
"Lu, Wenzhuo" <wenzhuo.lu@intel.com>,
"Adrien Mazarguil" <adrien.mazarguil@6wind.com>
Subject: Re: [dpdk-dev] [PATCH] net: introduce big and little endian types
Date: Tue, 6 Dec 2016 12:29:27 -0500 [thread overview]
Message-ID: <20161206172927.GA18116@hmsreliant.think-freely.org> (raw)
In-Reply-To: <2601191342CEEE43887BDE71AB9772583F0E4AC3@irsmsx105.ger.corp.intel.com>
On Tue, Dec 06, 2016 at 05:00:05PM +0000, Ananyev, Konstantin wrote:
>
>
> > -----Original Message-----
> > From: Nélio Laranjeiro [mailto:nelio.laranjeiro@6wind.com]
> > Sent: Tuesday, December 6, 2016 4:28 PM
> > To: Morten Brørup <mb@smartsharesystems.com>
> > Cc: Wiles, Keith <keith.wiles@intel.com>; Ananyev, Konstantin <konstantin.ananyev@intel.com>; Richardson, Bruce
> > <bruce.richardson@intel.com>; dev@dpdk.org; Olivier Matz <olivier.matz@6wind.com>; Lu, Wenzhuo <wenzhuo.lu@intel.com>; Adrien
> > Mazarguil <adrien.mazarguil@6wind.com>
> > Subject: Re: [dpdk-dev] [PATCH] net: introduce big and little endian types
> >
> > Hi all,
> >
> > On Tue, Dec 06, 2016 at 04:34:07PM +0100, Morten Brørup wrote:
> > > Hi all,
> > >
> > > Being a big fan of strong typing, I really like the concept of
> > > explicit endian types. Especially if type mismatches can be caught at
> > > compile time.
> >
> > +1,
> >
> > > However, I think it is too late! That train left the station when the
> > > rest of the world - including libraries and headers that might be
> > > linked with a DPDK application - decided to use implicit big endian
> > > types for network protocols, and has been doing so for decades. And,
> > > with all respect, I don't think the DPDK community has the momentum
> > > required to change this tradition outside the community.
> >
> > I don't think, those types can be use from now on to help new API to
> > expose explicitly the type they are handling. For older ones, it can
> > come in a second step, even if there are not so numerous. Only few of
> > them touches the network types.
> >
> > > Furthermore: If not enforced throughout DPDK (and beyond), it might
> > > confuse more than it helps.
> >
> > The current situation is more confusing, nobody at any layer can rely
> > on a precise information, at each function entry we need to verify if
> > the callee has already handled the job. The only solution is to browse
> > the code to have this information.
> >
> > Think about any function manipulating network headers (like flow director
> > or rte_flow) from the API down to the PMD, it may take a lot of time to
> > know at the end if the data is CPU or network ordered, with those types
> > it takes less than a second.
>
> Hmm, suppose I have such piece of code:
>
> struct ipv4_hdr iph;
> iph.total_length = val0;
> iph.packet_id = val1;
> ...
> iph.dst_addr = valn;
>
> hton_whole_ipv4_hdr_at_once(&iph);
>
> How I suppose to indicate via these new types that
> hton_whole_ipv4_hdr_at_once() expects ipv4_hdr fields in host byte order?
> Other than just putting it into the doc?
> Konstantin
>
You aren't. Your implication is correct in that, if you have a struct that
needs to store data in either cpu endian order or in network endian order, its
best to leave endian tagging out of the type, because it will by definition be
wrong at least 50% of the team, leading to more confusion than it rectifies
That isn't to say that endian coded types don't have a place. They're often
fairly useful when reading hardware registers and the like, or if a speciic bit
of data is to be extracted from a network payload. But in the use case above,
no, its not useful.
The best idea it seems is to provide the types, as well as endian-typed and
untyped variants to the endian conversion routines, so that developers can
choose what works best for them. Since the conversions are all macros with
casts anyway, it should be a no harm no foul addition in my mind.
To be clear, I don't support the patch as it exists, but I would support a
variant that just offered the types and conversion routines.
Neil
>
>
>
>
next prev parent reply other threads:[~2016-12-06 17:29 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-09 15:04 Nelio Laranjeiro
2016-12-05 10:09 ` Ananyev, Konstantin
2016-12-05 12:06 ` Nélio Laranjeiro
2016-12-06 11:23 ` Ananyev, Konstantin
2016-12-06 11:55 ` Bruce Richardson
2016-12-06 12:41 ` Ananyev, Konstantin
2016-12-06 13:34 ` Bruce Richardson
2016-12-06 14:45 ` Ananyev, Konstantin
2016-12-06 14:56 ` Wiles, Keith
2016-12-06 15:34 ` Morten Brørup
2016-12-06 16:28 ` Nélio Laranjeiro
2016-12-06 16:31 ` Wiles, Keith
2016-12-06 16:36 ` Richardson, Bruce
2016-12-06 17:00 ` Ananyev, Konstantin
2016-12-06 17:29 ` Neil Horman [this message]
2016-12-06 13:14 ` Nélio Laranjeiro
2016-12-06 13:30 ` Bruce Richardson
2016-12-06 14:06 ` Wiles, Keith
2016-12-08 9:30 ` Nélio Laranjeiro
2016-12-08 13:59 ` Wiles, Keith
2016-12-08 16:06 ` Thomas Monjalon
2016-12-08 15:07 ` Neil Horman
2016-12-08 15:10 ` Ananyev, Konstantin
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=20161206172927.GA18116@hmsreliant.think-freely.org \
--to=nhorman@tuxdriver.com \
--cc=adrien.mazarguil@6wind.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=keith.wiles@intel.com \
--cc=konstantin.ananyev@intel.com \
--cc=mb@smartsharesystems.com \
--cc=nelio.laranjeiro@6wind.com \
--cc=olivier.matz@6wind.com \
--cc=wenzhuo.lu@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).