Add cmd line parser

[Fredi-raspall]

goal: allow dataplane process to get other params, non-EAL related.

The crate used, clap, allows deriving parser functions automatically and defining default values.
However, that does not seem to work for certain types. We should also decide which args we can default and which ones are mandatory. We could default ALL (and then it would behave as it was, with stuff hardcoded).

We should also decide if we want to call the main proces "dataplane" or gateway?

A next-gen dataplane for next-gen fabric gateway

Usage: dataplane [OPTIONS]

Options:
      --main-lcore <core-id used as main>              [default: 2]
      --lcores <map lcore set to cpu set>              
      --in-memory                                      
      --allow <PCI devices to probe>                   
      --huge-worker-stack <huge pages>                 [default: 8192]
      --socket-mem <socket memory>                     
      --no-telemetry                                   
      --iova-mode <iova mode(va|pa)>                   
      --log-level <loglevel for a specific component>  
  -h, --help                                           Print help
  -V, --version                                        Print version

[daniel-noland]

Overall I really like this PR.

I had a number of comments, but only two actual concerns.

Address comments or ping me on slack and we can discuss.

NIce work :)

[daniel-noland]

We should also decide if we want to call the main proces "dataplane" or gateway?

This is a good question.

On thinking about it, I suggest that we convert the dataplane crate into a library and make another (much smaller) crate called gateway which is limited to things like parsing command line parameters and calling dataplane functions.

I am a big believer in thin applications and fat libraries. It makes testing easier, and who knows when we might want to recycle dataplane logic for some other purpose.

[Fredi-raspall]

Overall I really like this PR.

I had a number of comments, but only two actual concerns.

Address comments or ping me on slack and we can discuss.

NIce work :)

Thanks ... Fine to discuss if you're around!

[Fredi-raspall]

@daniel-noland I've pushed some changes and also renamed the crate to "gateway". I have NOT changed the name of the dataplane folder so as not to confuse folks that have outstanding PRs.
I've had to rename the folder too. Otherwise cargo fmt was complaining.
If we want to rename it, better sooner than later. I'm fine with other names btw!

[qmonnet]

What's the motivation for renaming dataplane to gateway?

[EDIT: Sorry I had missed part of the conversation. I like Daniel's suggestion of a dataplane library + gateway binary, for what it's worth.]

[mvachhar]

What's the motivation for renaming dataplane to gateway?

[EDIT: Sorry I had missed part of the conversation. I like Daniel's suggestion of a dataplane library + gateway binary, for what it's worth.]

I like the suggestion as well, though this repo is really just the dataplane as the full gateway as FRR, the agent etc. I'm open to a better name for either the dataplane library or gateway binary. We can also have a binary called dataplane and library called dataplane built out of the same crate.

[Fredi-raspall]

What's the motivation for renaming dataplane to gateway?
[EDIT: Sorry I had missed part of the conversation. I like Daniel's suggestion of a dataplane library + gateway binary, for what it's worth.]

I like the suggestion as well, though this repo is really just the dataplane as the full gateway as FRR, the agent etc. I'm open to a better name for either the dataplane library or gateway binary. We can also have a binary called dataplane and library called dataplane built out of the same crate.

I think dataplane is a bit unspecific. True, this repo does not contain the whole thing. Happy to rename it in any other way. Else, we can keep on having dataplane library and dataplane binary, altough a different name would make the distinction more explicit and keep generic stuff in the library and specifics in the binary. I can remove those commits from this PR since the original purpose of this PR was another.

[Fredi-raspall]

What's the motivation for renaming dataplane to gateway?
[EDIT: Sorry I had missed part of the conversation. I like Daniel's suggestion of a dataplane library + gateway binary, for what it's worth.]

I like the suggestion as well, though this repo is really just the dataplane as the full gateway as FRR, the agent etc. I'm open to a better name for either the dataplane library or gateway binary. We can also have a binary called dataplane and library called dataplane built out of the same crate.

I think dataplane is a bit unspecific. True, this repo does not contain the whole thing. Happy to rename it in any other way. Else, we can keep on having dataplane library and dataplane binary, altough a different name would make the distinction more explicit and keep generic stuff in the library and specifics in the binary. I can remove those commits from this PR since the original purpose of this PR was another.

@mvachhar I've removed the patches that do any rename. There is one outstanding comment from @daniel-noland regarding the logging.

[qmonnet]

Looks good to me, thank you

[qmonnet]

Seems good to merge as far as I can tell. The logging thing can be refined as a follow-up if necessary.

Review's comments have been addressed. The remaining discussion about logging can be addressed as a follow-up, if need be.

[daniel-noland]

I agree. Sorry I was out of action for a bit there. All ahead full!