DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: Matthew Hall <mhall@mhcomputing.net>,
	"Wu, Jingjing" <jingjing.wu@intel.com>,
	Antti Kantee <pooka@fixup.fi>, "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] symbol conflicts between netinet/in.h, arpa/inet.h, and rte_ip.h
Date: Fri, 25 Jul 2014 10:33:37 +0000	[thread overview]
Message-ID: <2601191342CEEE43887BDE71AB97725821343BA7@IRSMSX105.ger.corp.intel.com> (raw)
In-Reply-To: <b45e77f2-df66-4973-ab40-bde62270c47d@email.android.com>


> 
> I don't know if it will work right on both Linux and BSD and/or if they also 100% agree with the libc / glibc values compiled into the
> system's .so files. That's the risk that you run if you don't have more complete support in the DPDK itself for these features.

Looking at linux and freebsd netinet/in.h files - I think it should work.
But I suppose we can test it on both freebsd and linux before submitting a patch.

> --
> Sent from my mobile device.
> 
> On July 24, 2014 6:12:18 PM PDT, "Wu, Jingjing" <jingjing.wu@intel.com> wrote:
> >Hello,
> >
> >We also notice these conflicts, we just planned to fix it in our new
> >feature development. The proposal is like:
> >
> >#ifndef _NETINET_IN_H
> >#ifndef _NETINET_IN_H_
> >
> >#define IPPROTO_IP     0
> > ... ...
> >#define IPPROTO_MAX  256
> >
> >#endif
> >#endif
> >
> >Do you think it is a good idea?
> >
> >> -----Original Message-----
> >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Antti Kantee
> >> Sent: Friday, July 25, 2014 6:56 AM
> >> To: Matthew Hall; dev@dpdk.org
> >> Subject: Re: [dpdk-dev] symbol conflicts between netinet/in.h,
> >arpa/inet.h, and rte_ip.h
> >>
> >> On 24/07/14 07:59, Matthew Hall wrote:
> >> > Hello,
> >> >
> >> > I ran into some weird symbol conflicts between system netinet/in.h
> >and DPDK
> >> > rte_ip.h. They have a lot of duplicated definitions for stuff like
> >IPPROTO_IP
> >> > and so on. This breaks when you want to use inet_pton from
> >arpa/inet.h,
> >> > because it includes netinet/in.h to define struct in_addr.
> >>
> >> I would namespace the definitions in DPDK, i.e. make them
> >> DPDK_IPPROTO_FOO etc.
> >>
> >> > Thus with all the conflicts it's impossible to use a DPDK IP struct
> >instead of
> >> > all the system's sockaddr stuff, to store a value from the system
> >copy of
> >> > inet_pton. This would be a common operation if, for example, you
> >want to
> >> > configure all the IP addresses on your box from a JSON file, which
> >is what I
> >> > was doing.
> >> >
> >> > The DPDK kludged around it internally by using a file called
> >> > cmdline_parse_ipaddr.c with private copies of these functions. But
> >it in my
> >> > opinion very unwisely marked all of the functions as static except
> >for
> >> > cmdline_parse_ipaddr, which only works on the DPDK's proprietary
> >argument
> >> > handling, and not with anything the user might have which is a
> >different
> >> > format.
> >>
> >> In my experience from years of fighting with more or less this exact
> >> same problem -- the fight is now thankfully over but the scars remain
> >--
> >> you either want to expose a complete set of types and provide support
> >> for everything, or you want to expose nothing.  Approaches where you
> >use
> >> cute definitions and reuse some host routines is like asking for an
> >> audience with Tyranthraxus when armed with a kitten.  It's that
> >doubly
> >> so if you don't have to and do it anyway.
> >>
> >> > So, it would be a big help for users if the macros in librte_net
> >files would
> >> > check if the symbols already existed, or if they had subheader
> >files available
> >> > to grab only non conflicting symbols, or if they would make a
> >proper .h and
> >> > factor all the inet_pton and inet_ntop inside the cmdline lib into
> >a place
> >> > where users can access them. It would also be a help if they had a
> >less ugly
> >> > equivalent to struct sockaddr, which let you work with IP addresses
> >a bit more
> >> > easily, such as something like this:
> >>
> >> Again, I recommend steering away from any tightrope approaches that
> >> "know" which types are non-conflicting, or pick out half-and-half
> >from
> >> the host and IP stack.  "Do, or do not, there is no half-and-half"


  reply	other threads:[~2014-07-25 10:32 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-24  7:59 Matthew Hall
2014-07-24 15:43 ` Niraj Sharma (nirajsha)
2014-07-24 22:55 ` Antti Kantee
2014-07-24 23:03   ` Matthew Hall
2014-07-25  1:12   ` Wu, Jingjing
2014-07-25  4:56     ` Matthew Hall
2014-07-25 10:33       ` Ananyev, Konstantin [this message]
2014-07-25 10:43   ` Thomas Monjalon
2014-07-25 14:40     ` Antti Kantee

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=2601191342CEEE43887BDE71AB97725821343BA7@IRSMSX105.ger.corp.intel.com \
    --to=konstantin.ananyev@intel.com \
    --cc=dev@dpdk.org \
    --cc=jingjing.wu@intel.com \
    --cc=mhall@mhcomputing.net \
    --cc=pooka@fixup.fi \
    /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).