DPDK patches and discussions
 help / color / mirror / Atom feed
From: Daniel Pharos <danielpharos@hotmail.com>
To: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] Compilation failure when disabling Cavium OCTEONTX	network PMD driver
Date: Mon, 8 Jul 2019 21:16:52 +0000	[thread overview]
Message-ID: <AM0PR0402MB38267D9972773C36CF37FFD5D3F60@AM0PR0402MB3826.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <AM0PR0402MB3826CA93FB8CB565A8BE1435D3F60@AM0PR0402MB3826.eurprd04.prod.outlook.com>

Huh, looks like I've been hitting "Reply" instead of the required "Reply all", and the mailing list got dropped from the CC. Below is our conversation so far (might be incomplete).


Kind regards,
DanielPharos

From: Daniel Pharos
Sent: 08 July 2019 22:50
To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
Subject: RE: [dpdk-dev] Compilation failure when disabling Cavium OCTEONTX network PMD driver

> Looks at the decencies, You cannot document this as it is not scale to document this for every driver.
> LDLIBS += -lrte_eal -lrte_mbuf -lrte_mempool -lrte_ring -lrte_ethdev -lrte_net -lrte_kvargs -lrte_common_octeontx -lrte_eventdev -lrte_bus_pci -lrte_bus_vdev
If it's too complex to even document, that's basically an admission one can't do it by hand either. All the more reason to have some automated script do the work.

> I know you cannot create nice patch with that approach.
I've seen configure+makefiles that do just that. It's a shame the way you've chosen to organize things cannot support this.

> use meson build if care about build time. It is super fast.
If your compile-process is spending more time in the makefile than actually compiling, you are doing it wrong. But hey, maybe you are right. Please tell me how to have meson build only the drivers that I need, with automatic dependency-resolving.


Kind regards,
DanielPharos


From: Jerin Jacob Kollanukkaran <jerinj@marvell.com<mailto:jerinj@marvell.com>>
Sent: 08 July 2019 21:17
To: Daniel Pharos <danielpharos@hotmail.com<mailto:danielpharos@hotmail.com>>
Subject: RE: [dpdk-dev] Compilation failure when disabling Cavium OCTEONTX network PMD driver



From: Daniel Pharos <danielpharos@hotmail.com<mailto:danielpharos@hotmail.com>>
Sent: Monday, July 8, 2019 11:17 PM
To: Jerin Jacob Kollanukkaran <jerinj@marvell.com<mailto:jerinj@marvell.com>>
Subject: [EXT] RE: [dpdk-dev] Compilation failure when disabling Cavium OCTEONTX network PMD driver

External Email
________________________________
> What is the difference between comment and expressing in makefile. It is already depected in makefile.
When toggling the config options, I'm already in the config file. I shouldn't have to open the makefile as well to manually read all the various LDLIBS lines, figure out which configuration option belongs to the library name it references, then go back to the config file to modify it, and then repeat the process for its dependencies as well.

[Jerin] Looks at the decencies, You cannot document this as it is not scale to document this for every driver.
LDLIBS += -lrte_eal -lrte_mbuf -lrte_mempool -lrte_ring -lrte_ethdev -lrte_net -lrte_kvargs -lrte_common_octeontx -lrte_eventdev -lrte_bus_pci -lrte_bus_vdev

> Send a patch if you think there is change required.
Since this would be something that would need to be enforced, it would need broad support to be maintained, something that appears to be lacking at the moment, even though we've just demonstrated its added value. So I'm not going to invest my time to make a nice patch; I'll just hack something together privately.

[Jerin] I know you cannot create nice patch with that approach.

> BTW, Any reason for disabling the config in first place, Is it to reduce the space?
It's mostly to reduce compile time. Why spend lots of CPU cycles (re-)compiling drivers and libraries I can't even use, because I don't have the hardware? Also, I'm of the "only compile what you need, the rest is a (security?) incident waiting to happen"-school. And finally, when building high-performance systems, I'd like to reduce the amount of bloatware it contains (yes, even if it doesn't get loaded). So personally, I'd ask the question the other way around: why are you (not you personally!) making me compile stuff I'm never going to need or use?

[Jerin] use meson build if care about build time. It is super fast.


Kind regards,
DanielPharos

From: Jerin Jacob Kollanukkaran <jerinj@marvell.com<mailto:jerinj@marvell.com>>
Sent: 07 July 2019 19:18
To: Daniel Pharos <danielpharos@hotmail.com<mailto:danielpharos@hotmail.com>>
Subject: Re: [dpdk-dev] Compilation failure when disabling Cavium OCTEONTX network PMD driver

What is the difference between comment and expressing in makefile. It is already depected in makefile. Send a patch if you think there is change required. BTW, Any reason for disabling the config in first place, Is it to reduce the space?
________________________________
From: Daniel Pharos <danielpharos@hotmail.com<mailto:danielpharos@hotmail.com>>
Sent: Sunday, July 7, 2019 10:35:34 PM
To: Jerin Jacob Kollanukkaran
Subject: [EXT] RE: [dpdk-dev] Compilation failure when disabling Cavium OCTEONTX network PMD driver

External Email

----------------------------------------------------------------------
> Like linux kernel Kconfig we don't have means to express the dependency In Kconfig.
Yes you do. You can add a comment explaining the dependencies, so I don't have to go through multiple "compile -> fail -> guess which option I need to turn off -> retry" cycles. Heck, the very fact that your first answer got it wrong (as in: it was incomplete) strongly suggests this needs to be documented in the one place where people messing with the options will see it: as a comment line right next to the relevant option.


Kind regards,
DanielPharos


-----Original Message-----
From: Jerin Jacob Kollanukkaran <jerinj@marvell.com<mailto:jerinj@marvell.com>>
Sent: 07 July 2019 17:00
To: Daniel Pharos <danielpharos@hotmail.com<mailto:danielpharos@hotmail.com>>
Subject: RE: [dpdk-dev] Compilation failure when disabling Cavium OCTEONTX network PMD driver

> -----Original Message-----
> From: Daniel Pharos <danielpharos@hotmail.com<mailto:danielpharos@hotmail.com>>
> Sent: Sunday, July 7, 2019 8:03 PM
> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com<mailto:jerinj@marvell.com>>
> Subject: [EXT] RE: [dpdk-dev] Compilation failure when disabling
> Cavium OCTEONTX network PMD driver
>
> External Email
>
> ----------------------------------------------------------------------
> Hi,
>
> It would be nice if the config/make file complained about such
> incompatible settings. Also, that still doesn't work:

The makefile already has dependency[1] for the specific driver.
Like linux kernel Kconfig we don't have means to express the dependency In Kconfig.

[1]
drivers/net/octeontx/Makefile
LDLIBS += -lrte_eal -lrte_mbuf -lrte_mempool -lrte_ring LDLIBS += -lrte_ethdev -lrte_net -lrte_kvargs -lrte_common_octeontx LDLIBS += -lrte_mempool_octeontx LDLIBS += -lrte_eventdev LDLIBS += -lrte_bus_pci LDLIBS += -lrte_bus_vdev






It would be nice if the config/make file complained about such incompatible settings. Also, that still doesn't work:



/home/ubuntu/Downloads/dpdk-19.05/build/lib/librte_mempool_octeontx.a(octeontx_fpavf.o): In function `octeontx_fpapf_pool_setup':

octeontx_fpavf.c:(.text+0x318): undefined reference to `octeontx_mbox_send'

/home/ubuntu/Downloads/dpdk-19.05/build/lib/librte_mempool_octeontx.a(octeontx_fpavf.o): In function `octeontx_fpapf_pool_destroy':

octeontx_fpavf.c:(.text+0x465): undefined reference to `octeontx_mbox_send'

/home/ubuntu/Downloads/dpdk-19.05/build/lib/librte_mempool_octeontx.a(octeontx_fpavf.o): In function `octeontx_fpapf_aura_attach':

octeontx_fpavf.c:(.text+0x538): undefined reference to `octeontx_mbox_send'

/home/ubuntu/Downloads/dpdk-19.05/build/lib/librte_mempool_octeontx.a(octeontx_fpavf.o): In function `octeontx_fpapf_aura_detach':

octeontx_fpavf.c:(.text+0x681): undefined reference to `octeontx_mbox_send'

/home/ubuntu/Downloads/dpdk-19.05/build/lib/librte_mempool_octeontx.a(octeontx_fpavf.o): In function `octeontx_fpapf_start_count':

octeontx_fpavf.c:(.text+0x7f8): undefined reference to `octeontx_mbox_send'

collect2: error: ld returned 1 exit status

/home/ubuntu/Downloads/dpdk-19.05/mk/rte.app.mk:404: recipe for target 'test' failed

make[3]: *** [test] Error 1

/home/ubuntu/Downloads/dpdk-19.05/mk/rte.subdir.mk:35: recipe for target 'test' failed

make[2]: *** [test] Error 2

/home/ubuntu/Downloads/dpdk-19.05/mk/rte.sdkbuild.mk:46: recipe for target 'app' failed

make[1]: *** [app] Error 2

/home/ubuntu/Downloads/dpdk-19.05/mk/rte.sdkroot.mk:98: recipe for target 'all' failed

make: *** [all] Error 2



(And yes, I did start with a clean extract from the tarball.)



I suspect there are more hidden dependencies than just that one. This compilation failure seems to suggest CONFIG_RTE_LIBRTE_OCTEONTX_MEMPOOL is also involved...





Kind regards,

DanielPharos


      parent reply	other threads:[~2019-07-08 22:09 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-06 15:11 Daniel Pharos
2019-07-07 13:00 ` Jerin Jacob Kollanukkaran
     [not found]   ` <AM0PR0402MB3826002A98D18716BA6359FAD3F70@AM0PR0402MB3826.eurprd04.prod.outlook.com>
     [not found]     ` <BYAPR18MB24247C55F57AF4FF16AFEA4AC8F70@BYAPR18MB2424.namprd18.prod.outlook.com>
     [not found]       ` <AM0PR0402MB3826109D818BFCB759E3B55CD3F70@AM0PR0402MB3826.eurprd04.prod.outlook.com>
     [not found]         ` <BYAPR18MB24243551F2EAADFBE6C151CFC8F70@BYAPR18MB2424.namprd18.prod.outlook.com>
     [not found]           ` <AM0PR0402MB3826565C7F5856751401D081D3F60@AM0PR0402MB3826.eurprd04.prod.outlook.com>
     [not found]             ` <BYAPR18MB24248589B21F5F628BD40B3BC8F60@BYAPR18MB2424.namprd18.prod.outlook.com>
     [not found]               ` <AM0PR0402MB3826CA93FB8CB565A8BE1435D3F60@AM0PR0402MB3826.eurprd04.prod.outlook.com>
2019-07-08 21:16                 ` Daniel Pharos [this message]

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=AM0PR0402MB38267D9972773C36CF37FFD5D3F60@AM0PR0402MB3826.eurprd04.prod.outlook.com \
    --to=danielpharos@hotmail.com \
    --cc=dev@dpdk.org \
    /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).