[dpdk-dev] [PKTGEN] fixing weird termio issues that complicate debugging

[dpdk-dev] [PKTGEN] fixing weird termio issues that complicate debugging

[Matthew Hall]

Hello,

Since the pktgen code is reindented I am finding time to read through it 
and experiment and see if I can get it working.

I have issues with the init process of pktgen. It is difficult to debug 
it because the init code does a lot of very scary stuff to the terminal 
control / TTY device at inconvenient times in an inconvenient order, and 
in the process damages the debug output and damages the screen of your 
GDB without doing weird things to run GDB on a different TTY.

Of course I am willing to contribute patches and not just complain, but 
first I need some help to follow what is going on.

Here is the problematic call-flow with some explanation what went wrong 
trying it on some community machines outside of its original environment:

1) it calls printf("\n%s %s\n", wr_copyright_msg(), wr_powered_by()); 
which dumps tons of weird boilerplate of licenses, copyrights, code 
creator, etc.

It is open source and everybody that matters already knows who coded it, 
so is this stuff really that important? This gets in the way when you 
are trying to work on it and I just have to comment it out.

2) it calls wr_scrn_setw and tinkers with the windows size very early in 
the init which can make your terminal weird

3) it calls rte_eal_init which produces a lot of nice debug output, 
which is fine

4) it calls pktgen_init_screen, which calls wr_scrn_init, which calls 
wr_scrn_erase which destroys the valuable debug output just created in 
(c) which is a bad thing

5) it calls wr_print_copyright and dumps more boilerplate I am not sure 
is needed

6) it logs some helpful messages about the port / descriptor settings 
which is fine

7) it calls the pktgen_config_ports function which can crash in ways you 
need the destroyed debug output to fix.

For example in my case that function crashes here:

         if (pktgen.nb_ports == 0)
                 pktgen_log_panic("*** Did not find any ports to use ***");

8) Later it makes a logo and a splash screen (wr_log, wr_splash_screen). 
Is this stuff really needed? This is a ton of output for just starting 
up some test program.

To fix this debug problem I propose some changes which I am happy to 
help develop:

1) decide what of this output we really need here and greatly simplify 
how much gets printed out

2) move wr_scrn_setw right before pktgen_init_screen and after 
rte_eal_init to prevent damaging that output

3) consider how wr_scrn_init is called in pktgen_init_screen, because it 
calls wr_scrn_erase which damages output

4) I think that pktgen_config_ports should be called before all this 
weird screen init stuff, so that if it fails you can actually see what 
happened there.

One other random topic... on the long lines of code it looks like there 
are some gigantic tab-indents pushing things off to the right still. One 
example, maybe there are others or another setting which is needed to 
fix all of these:

                 info->seq_pkt = (pkt_seq_t *)rte_zmalloc_socket(buff, 
(sizeof(pkt_seq_t) * NUM_TOTAL_PKTS),
 
                                          RTE_CACHE_LINE_SIZE, 
rte_socket_id());

Thoughts?
Matthew Hall

Re: [dpdk-dev] [PKTGEN] fixing weird termio issues that complicate debugging

[Panu Matilainen]

On 01/20/2016 08:32 AM, Matthew Hall wrote:
> Hello,
>
> Since the pktgen code is reindented I am finding time to read through it
> and experiment and see if I can get it working.
>
> I have issues with the init process of pktgen. It is difficult to debug
> it because the init code does a lot of very scary stuff to the terminal
> control / TTY device at inconvenient times in an inconvenient order, and
> in the process damages the debug output and damages the screen of your
> GDB without doing weird things to run GDB on a different TTY.
>
> Of course I am willing to contribute patches and not just complain, but
> first I need some help to follow what is going on.
>
> Here is the problematic call-flow with some explanation what went wrong
> trying it on some community machines outside of its original environment:
>
> 1) it calls printf("\n%s %s\n", wr_copyright_msg(), wr_powered_by());
> which dumps tons of weird boilerplate of licenses, copyrights, code
> creator, etc.
>
> It is open source and everybody that matters already knows who coded it,
> so is this stuff really that important? This gets in the way when you
> are trying to work on it and I just have to comment it out.
>
> 2) it calls wr_scrn_setw and tinkers with the windows size very early in
> the init which can make your terminal weird
>
> 3) it calls rte_eal_init which produces a lot of nice debug output,
> which is fine
>
> 4) it calls pktgen_init_screen, which calls wr_scrn_init, which calls
> wr_scrn_erase which destroys the valuable debug output just created in
> (c) which is a bad thing
>
> 5) it calls wr_print_copyright and dumps more boilerplate I am not sure
> is needed
>
> 6) it logs some helpful messages about the port / descriptor settings
> which is fine
>
> 7) it calls the pktgen_config_ports function which can crash in ways you
> need the destroyed debug output to fix.
>
> For example in my case that function crashes here:
>
>          if (pktgen.nb_ports == 0)
>                  pktgen_log_panic("*** Did not find any ports to use ***");
>
> 8) Later it makes a logo and a splash screen (wr_log, wr_splash_screen).
> Is this stuff really needed? This is a ton of output for just starting
> up some test program.
>
> To fix this debug problem I propose some changes which I am happy to
> help develop:
>
> 1) decide what of this output we really need here and greatly simplify
> how much gets printed out
>
> 2) move wr_scrn_setw right before pktgen_init_screen and after
> rte_eal_init to prevent damaging that output
>
> 3) consider how wr_scrn_init is called in pktgen_init_screen, because it
> calls wr_scrn_erase which damages output
>
> 4) I think that pktgen_config_ports should be called before all this
> weird screen init stuff, so that if it fails you can actually see what
> happened there.
>
> One other random topic... on the long lines of code it looks like there
> are some gigantic tab-indents pushing things off to the right still. One
> example, maybe there are others or another setting which is needed to
> fix all of these:
>
>                  info->seq_pkt = (pkt_seq_t *)rte_zmalloc_socket(buff,
> (sizeof(pkt_seq_t) * NUM_TOTAL_PKTS),
>
>                                           RTE_CACHE_LINE_SIZE,
> rte_socket_id());
>
> Thoughts?

Just that I'm in violent agreement about the splash screens and all.
Unfortunately the license explicitly forbids removal of the copyright 
messages (http://dpdk.org/browse/apps/pktgen-dpdk/tree/LICENSE#n18):

--
# 4) The screens displayed by the application must contain the copyright 
notice as defined
# above and can not be removed without specific prior written permission.
--

Keith, any chance you could work out the details with Wind River to get 
the ridiculous startup messages straightened out? I dont think anybody 
would mind a line or two "copyright by..." kind of printf() in there if 
that's what it takes, but the current screen after screen after screen 
copyrights and advertisements are obnoxious to the point of driving 
potential users away.

	- Panu -

> Matthew Hall

Re: [dpdk-dev] [PKTGEN] fixing weird termio issues that complicate debugging

[Wiles, Keith]

On 1/20/16, 12:32 AM, "dev on behalf of Matthew Hall" <dev-bounces@dpdk.org on behalf of mhall@mhcomputing.net> wrote:

Hi Matthew,

I have some comments below, but will address your full email later when I have a bit more time.

>Hello,
>
>Since the pktgen code is reindented I am finding time to read through it 
>and experiment and see if I can get it working.
>
>I have issues with the init process of pktgen. It is difficult to debug 
>it because the init code does a lot of very scary stuff to the terminal 
>control / TTY device at inconvenient times in an inconvenient order, and 
>in the process damages the debug output and damages the screen of your 
>GDB without doing weird things to run GDB on a different TTY.
>
>Of course I am willing to contribute patches and not just complain, but 
>first I need some help to follow what is going on.
>
>Here is the problematic call-flow with some explanation what went wrong 
>trying it on some community machines outside of its original environment:
>
>1) it calls printf("\n%s %s\n", wr_copyright_msg(), wr_powered_by()); 
>which dumps tons of weird boilerplate of licenses, copyrights, code 
>creator, etc.
>
>It is open source and everybody that matters already knows who coded it, 
>so is this stuff really that important? This gets in the way when you 
>are trying to work on it and I just have to comment it out.
>
>2) it calls wr_scrn_setw and tinkers with the windows size very early in 
>the init which can make your terminal weird
>
>3) it calls rte_eal_init which produces a lot of nice debug output, 
>which is fine
>
>4) it calls pktgen_init_screen, which calls wr_scrn_init, which calls 
>wr_scrn_erase which destroys the valuable debug output just created in 
>(c) which is a bad thing
>
>5) it calls wr_print_copyright and dumps more boilerplate I am not sure 
>is needed
>
>6) it logs some helpful messages about the port / descriptor settings 
>which is fine
>
>7) it calls the pktgen_config_ports function which can crash in ways you 
>need the destroyed debug output to fix.
>
>For example in my case that function crashes here:
>
>         if (pktgen.nb_ports == 0)
>                 pktgen_log_panic("*** Did not find any ports to use ***");

This problem is DPDK did not find any ports to use for Pktgen. Please check to make sure you have the right ports attached to gib_uio and they are usable by DPDK.
>
>8) Later it makes a logo and a splash screen (wr_log, wr_splash_screen). 
>Is this stuff really needed? This is a ton of output for just starting 
>up some test program.
>
>To fix this debug problem I propose some changes which I am happy to 
>help develop:
>
>1) decide what of this output we really need here and greatly simplify 
>how much gets printed out
>
>2) move wr_scrn_setw right before pktgen_init_screen and after 
>rte_eal_init to prevent damaging that output
>
>3) consider how wr_scrn_init is called in pktgen_init_screen, because it 
>calls wr_scrn_erase which damages output
>
>4) I think that pktgen_config_ports should be called before all this 
>weird screen init stuff, so that if it fails you can actually see what 
>happened there.
>
>One other random topic... on the long lines of code it looks like there 
>are some gigantic tab-indents pushing things off to the right still. One 
>example, maybe there are others or another setting which is needed to 
>fix all of these:

Please use tab stops of 4 instead of 8.
>
>                 info->seq_pkt = (pkt_seq_t *)rte_zmalloc_socket(buff, 
>(sizeof(pkt_seq_t) * NUM_TOTAL_PKTS),
> 
>                                          RTE_CACHE_LINE_SIZE, 
>rte_socket_id());
>
>Thoughts?
>Matthew Hall
>


Regards,
Keith

Re: [dpdk-dev] [PKTGEN] fixing weird termio issues that complicate debugging

[Wiles, Keith]

On 1/20/16, 12:32 AM, "dev on behalf of Matthew Hall" <dev-bounces@dpdk.org on behalf of mhall@mhcomputing.net> wrote:

>Hello,
>
>Since the pktgen code is reindented I am finding time to read through it 
>and experiment and see if I can get it working.
>
>I have issues with the init process of pktgen. It is difficult to debug 
>it because the init code does a lot of very scary stuff to the terminal 
>control / TTY device at inconvenient times in an inconvenient order, and 
>in the process damages the debug output and damages the screen of your 
>GDB without doing weird things to run GDB on a different TTY.
>
>Of course I am willing to contribute patches and not just complain, but 
>first I need some help to follow what is going on.
>
>Here is the problematic call-flow with some explanation what went wrong 
>trying it on some community machines outside of its original environment:
>
>1) it calls printf("\n%s %s\n", wr_copyright_msg(), wr_powered_by()); 
>which dumps tons of weird boilerplate of licenses, copyrights, code 
>creator, etc.
>
>It is open source and everybody that matters already knows who coded it, 
>so is this stuff really that important? This gets in the way when you 
>are trying to work on it and I just have to comment it out.

One problem is a number of people wanted to steal the code and use in a paid application, so the copyright is some what a requirement. As you may know I do a lot of debugging on Pktgen and I feel they are a nuisance. I can try to see if we can clean up these messages, but do not hold your breath on getting them to be removed. 
>
>2) it calls wr_scrn_setw and tinkers with the windows size very early in 
>the init which can make your terminal weird
>
>3) it calls rte_eal_init which produces a lot of nice debug output, 
>which is fine

IMO most of the information from DPDK is not very useful as why do I need to see every lcore line, plus a lot of more useless information. Most of the information could be reduced a couple of lines or only report issues not just a bunch of useless information.
>
>4) it calls pktgen_init_screen, which calls wr_scrn_init, which calls 
>wr_scrn_erase which destroys the valuable debug output just created in 
>(c) which is a bad thing

The screen init should be scrolling the information off the screen to preserve that info, unless it was changed by mistake.
>
>5) it calls wr_print_copyright and dumps more boilerplate I am not sure 
>is needed
>
>6) it logs some helpful messages about the port / descriptor settings 
>which is fine
>
>7) it calls the pktgen_config_ports function which can crash in ways you 
>need the destroyed debug output to fix.
>
>For example in my case that function crashes here:
>
>         if (pktgen.nb_ports == 0)
>                 pktgen_log_panic("*** Did not find any ports to use ***");
>
>8) Later it makes a logo and a splash screen (wr_log, wr_splash_screen). 
>Is this stuff really needed? This is a ton of output for just starting 
>up some test program.
>
>To fix this debug problem I propose some changes which I am happy to 
>help develop:
>
>1) decide what of this output we really need here and greatly simplify 
>how much gets printed out
>
>2) move wr_scrn_setw right before pktgen_init_screen and after 
>rte_eal_init to prevent damaging that output
>
>3) consider how wr_scrn_init is called in pktgen_init_screen, because it 
>calls wr_scrn_erase which damages output

Again it could be scrolling that information off the screen, just need a large screen scroll buffer.
>
>4) I think that pktgen_config_ports should be called before all this 
>weird screen init stuff, so that if it fails you can actually see what 
>happened there.
>
>One other random topic... on the long lines of code it looks like there 
>are some gigantic tab-indents pushing things off to the right still. One 
>example, maybe there are others or another setting which is needed to 
>fix all of these:

Please use tab stop of 4 instead of 8. IMO tab stop of 8 is so 1970’s and we should not need tab stop of 8 as any system today will work. :-)
>
>                 info->seq_pkt = (pkt_seq_t *)rte_zmalloc_socket(buff, 
>(sizeof(pkt_seq_t) * NUM_TOTAL_PKTS),
> 
>                                          RTE_CACHE_LINE_SIZE, 
>rte_socket_id());
>
>Thoughts?
>Matthew Hall

Improvement to Pktgen is always welcome and the copyright info is going to be a bit hard to remove as that was one of the requirements when I open sourced the code. I understand it maybe a bit of output. I do not think it is really a user issue causing users to stop using it as startup is only down once, in my case I may start Pktgen a few times a day for development and it does not seem to slow me down much. :-)
>


Regards,
Keith

Re: [dpdk-dev] [PKTGEN] fixing weird termio issues that complicate debugging

[Wiles, Keith]

On 1/20/16, 10:26 AM, "dev on behalf of Wiles, Keith" <dev-bounces@dpdk.org on behalf of keith.wiles@intel.com> wrote:

>On 1/20/16, 12:32 AM, "dev on behalf of Matthew Hall" <dev-bounces@dpdk.org on behalf of mhall@mhcomputing.net> wrote:
>
>>Hello,

Please try modifying pktgen-main.c:main() at the top of the function to this:

    wr_scrn_setw(1);		/* Reset the window size, from possible crash run. */
    wr_scrn_pos(100, 1);	/* Move the cursor to the bottom of the screen again */

    printf("\n%s %s\n", wr_copyright_msg(), wr_powered_by()); fflush(stdout);

    /* call before the rte_eal_init() */
    (void)rte_set_application_usage_hook(pktgen_usage);

Maybe this will fix up most of your issues with DPDK output. I normally set the log-level to 7 to remove most of the DPDK messages.


>>
>>Since the pktgen code is reindented I am finding time to read through it 
>>and experiment and see if I can get it working.
>>
>>I have issues with the init process of pktgen. It is difficult to debug 
>>it because the init code does a lot of very scary stuff to the terminal 
>>control / TTY device at inconvenient times in an inconvenient order, and 
>>in the process damages the debug output and damages the screen of your 
>>GDB without doing weird things to run GDB on a different TTY.
>>
>>Of course I am willing to contribute patches and not just complain, but 
>>first I need some help to follow what is going on.
>>
>>Here is the problematic call-flow with some explanation what went wrong 
>>trying it on some community machines outside of its original environment:
>>
>>1) it calls printf("\n%s %s\n", wr_copyright_msg(), wr_powered_by()); 
>>which dumps tons of weird boilerplate of licenses, copyrights, code 
>>creator, etc.
>>
>>It is open source and everybody that matters already knows who coded it, 
>>so is this stuff really that important? This gets in the way when you 
>>are trying to work on it and I just have to comment it out.
>
>One problem is a number of people wanted to steal the code and use in a paid application, so the copyright is some what a requirement. As you may know I do a lot of debugging on Pktgen and I feel they are a nuisance. I can try to see if we can clean up these messages, but do not hold your breath on getting them to be removed. 
>>
>>2) it calls wr_scrn_setw and tinkers with the windows size very early in 
>>the init which can make your terminal weird
>>
>>3) it calls rte_eal_init which produces a lot of nice debug output, 
>>which is fine
>
>IMO most of the information from DPDK is not very useful as why do I need to see every lcore line, plus a lot of more useless information. Most of the information could be reduced a couple of lines or only report issues not just a bunch of useless information.
>>
>>4) it calls pktgen_init_screen, which calls wr_scrn_init, which calls 
>>wr_scrn_erase which destroys the valuable debug output just created in 
>>(c) which is a bad thing
>
>The screen init should be scrolling the information off the screen to preserve that info, unless it was changed by mistake.
>>
>>5) it calls wr_print_copyright and dumps more boilerplate I am not sure 
>>is needed
>>
>>6) it logs some helpful messages about the port / descriptor settings 
>>which is fine
>>
>>7) it calls the pktgen_config_ports function which can crash in ways you 
>>need the destroyed debug output to fix.
>>
>>For example in my case that function crashes here:
>>
>>         if (pktgen.nb_ports == 0)
>>                 pktgen_log_panic("*** Did not find any ports to use ***");
>>
>>8) Later it makes a logo and a splash screen (wr_log, wr_splash_screen). 
>>Is this stuff really needed? This is a ton of output for just starting 
>>up some test program.
>>
>>To fix this debug problem I propose some changes which I am happy to 
>>help develop:
>>
>>1) decide what of this output we really need here and greatly simplify 
>>how much gets printed out
>>
>>2) move wr_scrn_setw right before pktgen_init_screen and after 
>>rte_eal_init to prevent damaging that output
>>
>>3) consider how wr_scrn_init is called in pktgen_init_screen, because it 
>>calls wr_scrn_erase which damages output
>
>Again it could be scrolling that information off the screen, just need a large screen scroll buffer.
>>
>>4) I think that pktgen_config_ports should be called before all this 
>>weird screen init stuff, so that if it fails you can actually see what 
>>happened there.
>>
>>One other random topic... on the long lines of code it looks like there 
>>are some gigantic tab-indents pushing things off to the right still. One 
>>example, maybe there are others or another setting which is needed to 
>>fix all of these:
>
>Please use tab stop of 4 instead of 8. IMO tab stop of 8 is so 1970’s and we should not need tab stop of 8 as any system today will work. :-)
>>
>>                 info->seq_pkt = (pkt_seq_t *)rte_zmalloc_socket(buff, 
>>(sizeof(pkt_seq_t) * NUM_TOTAL_PKTS),
>> 
>>                                          RTE_CACHE_LINE_SIZE, 
>>rte_socket_id());
>>
>>Thoughts?
>>Matthew Hall
>
>Improvement to Pktgen is always welcome and the copyright info is going to be a bit hard to remove as that was one of the requirements when I open sourced the code. I understand it maybe a bit of output. I do not think it is really a user issue causing users to stop using it as startup is only down once, in my case I may start Pktgen a few times a day for development and it does not seem to slow me down much. :-)
>>
>
>
>Regards,
>Keith
>
>
>
>
>


Regards,
Keith

Re: [dpdk-dev] [PKTGEN] fixing weird termio issues that complicate debugging

[Matthew Hall]

On 1/20/16 8:26 AM, Wiles, Keith wrote:
> One problem is a number of people wanted to steal the code and use in a paid application, so the copyright is some what a requirement. As you may know I do a lot of debugging on Pktgen and I feel they are a nuisance. I can try to see if we can clean up these messages, but do not hold your breath on getting them to be removed.

Understood, I am just providing some usability feedback from the 
community. Any cleanup, however partial it may be for other reasons, 
will personally aid me in simplicity of debugging and using the pktgen 
to find performance improvements in other community applications and 
DPDK itself, which is my true end goal here. In particular I need it for 
all the changes I posted at various points for librte_lpm so I can test 
all this stuff to make sure it really works.

> IMO most of the information from DPDK is not very useful as why do I need to see every lcore line, plus a lot of more useless information. Most of the information could be reduced a couple of lines or only report issues not just a bunch of useless information.

DPDK's messages might not be helpful for you, but in my case, the 
temporary hostile modifications I made based on the writeup sent 
previously, in order to make these messages visible again, is what 
allowed me to find and fix the root causes of my inactive port issues, 
because I have been working with DPDK's messages since 2011 and am very 
familiar with what they mean inside DPDK itself, so they were the only 
UI of Pktgen familiar to me at all compared to the rest which is custom 
stuff I didn't use before.

> The screen init should be scrolling the information off the screen to preserve that info, unless it was changed by mistake.

I found a lot of info is being overwritten or lost due to the complex 
sequence of all these calls. This is what led to my email of questions 
for you.

> Please use tab stop of 4 instead of 8. IMO tab stop of 8 is so 1970’s and we should not need tab stop of 8 as any system today will work. :-)

OK. But do note that this convention is different from every other 
project I've coded on before.

Sincerely,
Matthew.

Re: [dpdk-dev] [PKTGEN] fixing weird termio issues that complicate debugging

[Panu Matilainen]

On 01/20/2016 06:26 PM, Wiles, Keith wrote:
> On 1/20/16, 12:32 AM, "dev on behalf of Matthew Hall" <dev-bounces@dpdk.org on behalf of mhall@mhcomputing.net> wrote:
>
>> Hello,
>>
>> Since the pktgen code is reindented I am finding time to read through it
>> and experiment and see if I can get it working.
>>
>> I have issues with the init process of pktgen. It is difficult to debug
>> it because the init code does a lot of very scary stuff to the terminal
>> control / TTY device at inconvenient times in an inconvenient order, and
>> in the process damages the debug output and damages the screen of your
>> GDB without doing weird things to run GDB on a different TTY.
>>
>> Of course I am willing to contribute patches and not just complain, but
>> first I need some help to follow what is going on.
>>
>> Here is the problematic call-flow with some explanation what went wrong
>> trying it on some community machines outside of its original environment:
>>
>> 1) it calls printf("\n%s %s\n", wr_copyright_msg(), wr_powered_by());
>> which dumps tons of weird boilerplate of licenses, copyrights, code
>> creator, etc.
>>
>> It is open source and everybody that matters already knows who coded it,
>> so is this stuff really that important? This gets in the way when you
>> are trying to work on it and I just have to comment it out.
>
> One problem is a number of people wanted to steal the code and use in
> a paid application, so the copyright is some what a requirement.

In that case, why is it under a BSD'ish license instead of something 
like GPL that's designed to prevent it in the first place? Might be too 
late to change it by now, just wondering.

> As you may know I do a lot of debugging on Pktgen and I feel they are
> a nuisance. I can try to see if we can clean up these messages, but
> do not hold your breath on getting them to be removed.

It would make a world of difference if it just printed the copyright etc 
in a couple of lines during startup, instead of taking over the entire 
screen for several seconds.

This is a whole lot like those anti-piracy ad campaigns on DVDs which 
you cant skip, so all the *legitimate* users are forced to suffer 
through them but all the bad guys just rip it out of their copies. DRM 
that ends up hurting the legitimate users the most is never a good idea.

	- Panu -

Re: [dpdk-dev] [PKTGEN] fixing weird termio issues that complicate debugging

[Wiles, Keith]

On 1/21/16, 2:46 AM, "Panu Matilainen" <pmatilai@redhat.com> wrote:

>On 01/20/2016 06:26 PM, Wiles, Keith wrote:
>> On 1/20/16, 12:32 AM, "dev on behalf of Matthew Hall" <dev-bounces@dpdk.org on behalf of mhall@mhcomputing.net> wrote:
>>
>>> Hello,
>>>
>>> Since the pktgen code is reindented I am finding time to read through it
>>> and experiment and see if I can get it working.
>>>
>>> I have issues with the init process of pktgen. It is difficult to debug
>>> it because the init code does a lot of very scary stuff to the terminal
>>> control / TTY device at inconvenient times in an inconvenient order, and
>>> in the process damages the debug output and damages the screen of your
>>> GDB without doing weird things to run GDB on a different TTY.
>>>
>>> Of course I am willing to contribute patches and not just complain, but
>>> first I need some help to follow what is going on.
>>>
>>> Here is the problematic call-flow with some explanation what went wrong
>>> trying it on some community machines outside of its original environment:
>>>
>>> 1) it calls printf("\n%s %s\n", wr_copyright_msg(), wr_powered_by());
>>> which dumps tons of weird boilerplate of licenses, copyrights, code
>>> creator, etc.
>>>
>>> It is open source and everybody that matters already knows who coded it,
>>> so is this stuff really that important? This gets in the way when you
>>> are trying to work on it and I just have to comment it out.
>>
>> One problem is a number of people wanted to steal the code and use in
>> a paid application, so the copyright is some what a requirement.
>
>In that case, why is it under a BSD'ish license instead of something 
>like GPL that's designed to prevent it in the first place? Might be too 
>late to change it by now, just wondering.

DPDK is BSD, so you can not use a GPL application with DPDK (I think) anyway I can try to speed you the screens, but does it really matter as these are only at startup and I normally leave pktgen running for long periods of time. The extra time at the start does not seem to be a big issue, right?

>
>> As you may know I do a lot of debugging on Pktgen and I feel they are
>> a nuisance. I can try to see if we can clean up these messages, but
>> do not hold your breath on getting them to be removed.
>
>It would make a world of difference if it just printed the copyright etc 
>in a couple of lines during startup, instead of taking over the entire 
>screen for several seconds.
>
>This is a whole lot like those anti-piracy ad campaigns on DVDs which 
>you cant skip, so all the *legitimate* users are forced to suffer 
>through them but all the bad guys just rip it out of their copies. DRM 
>that ends up hurting the legitimate users the most is never a good idea.
>
>	- Panu -
>
>
>


Regards,
Keith

Re: [dpdk-dev] [PKTGEN] fixing weird termio issues that complicate debugging

[Stephen Hemminger]

On Thu, 21 Jan 2016 15:03:37 +0000
"Wiles, Keith" <keith.wiles@intel.com> wrote:

> On 1/21/16, 2:46 AM, "Panu Matilainen" <pmatilai@redhat.com> wrote:
> 
> >On 01/20/2016 06:26 PM, Wiles, Keith wrote:
> >> On 1/20/16, 12:32 AM, "dev on behalf of Matthew Hall" <dev-bounces@dpdk.org on behalf of mhall@mhcomputing.net> wrote:
> >>
> >>> Hello,
> >>>
> >>> Since the pktgen code is reindented I am finding time to read through it
> >>> and experiment and see if I can get it working.
> >>>
> >>> I have issues with the init process of pktgen. It is difficult to debug
> >>> it because the init code does a lot of very scary stuff to the terminal
> >>> control / TTY device at inconvenient times in an inconvenient order, and
> >>> in the process damages the debug output and damages the screen of your
> >>> GDB without doing weird things to run GDB on a different TTY.
> >>>
> >>> Of course I am willing to contribute patches and not just complain, but
> >>> first I need some help to follow what is going on.
> >>>
> >>> Here is the problematic call-flow with some explanation what went wrong
> >>> trying it on some community machines outside of its original environment:
> >>>
> >>> 1) it calls printf("\n%s %s\n", wr_copyright_msg(), wr_powered_by());
> >>> which dumps tons of weird boilerplate of licenses, copyrights, code
> >>> creator, etc.
> >>>
> >>> It is open source and everybody that matters already knows who coded it,
> >>> so is this stuff really that important? This gets in the way when you
> >>> are trying to work on it and I just have to comment it out.
> >>
> >> One problem is a number of people wanted to steal the code and use in
> >> a paid application, so the copyright is some what a requirement.
> >
> >In that case, why is it under a BSD'ish license instead of something 
> >like GPL that's designed to prevent it in the first place? Might be too 
> >late to change it by now, just wondering.
> 
> DPDK is BSD, so you can not use a GPL application with DPDK (I think) anyway I can try to speed you the screens, but does it really matter as these are only at startup and I normally leave pktgen running for long periods of time. The extra time at the start does not seem to be a big issue, right?
> 
> >
> >> As you may know I do a lot of debugging on Pktgen and I feel they are
> >> a nuisance. I can try to see if we can clean up these messages, but
> >> do not hold your breath on getting them to be removed.
> >
> >It would make a world of difference if it just printed the copyright etc 
> >in a couple of lines during startup, instead of taking over the entire 
> >screen for several seconds.
> >
> >This is a whole lot like those anti-piracy ad campaigns on DVDs which 
> >you cant skip, so all the *legitimate* users are forced to suffer 
> >through them but all the bad guys just rip it out of their copies. DRM 
> >that ends up hurting the legitimate users the most is never a good idea.
> >
> >	- Panu -
> >
> >
> >
> 
> 
> Regards,
> Keith

I would rip out the whole tty control and theming nonsense and then
just print one line copyright on startup.

Re: [dpdk-dev] [PKTGEN] fixing weird termio issues that complicate debugging

[Matthew Hall]

On Thu, Jan 21, 2016 at 11:00:14AM -0800, Stephen Hemminger wrote:
> I would rip out the whole tty control and theming nonsense and then
> just print one line copyright on startup.

Personally, I might have put this sentiment more diplomatically, but a 
refactor effort such as this would make life easier for me coming from the 
community trying to work with this tool.

When I get a bit deeper into it, I'll see if I can help.

Matthew.

Re: [dpdk-dev] [PKTGEN] fixing weird termio issues that complicate debugging

[Panu Matilainen]

On 01/21/2016 05:03 PM, Wiles, Keith wrote:
> On 1/21/16, 2:46 AM, "Panu Matilainen" <pmatilai@redhat.com> wrote:
>
>> On 01/20/2016 06:26 PM, Wiles, Keith wrote:
>>> On 1/20/16, 12:32 AM, "dev on behalf of Matthew Hall" <dev-bounces@dpdk.org on behalf of mhall@mhcomputing.net> wrote:
>>>
>>>> Hello,
>>>>
>>>> Since the pktgen code is reindented I am finding time to read through it
>>>> and experiment and see if I can get it working.
>>>>
>>>> I have issues with the init process of pktgen. It is difficult to debug
>>>> it because the init code does a lot of very scary stuff to the terminal
>>>> control / TTY device at inconvenient times in an inconvenient order, and
>>>> in the process damages the debug output and damages the screen of your
>>>> GDB without doing weird things to run GDB on a different TTY.
>>>>
>>>> Of course I am willing to contribute patches and not just complain, but
>>>> first I need some help to follow what is going on.
>>>>
>>>> Here is the problematic call-flow with some explanation what went wrong
>>>> trying it on some community machines outside of its original environment:
>>>>
>>>> 1) it calls printf("\n%s %s\n", wr_copyright_msg(), wr_powered_by());
>>>> which dumps tons of weird boilerplate of licenses, copyrights, code
>>>> creator, etc.
>>>>
>>>> It is open source and everybody that matters already knows who coded it,
>>>> so is this stuff really that important? This gets in the way when you
>>>> are trying to work on it and I just have to comment it out.
>>>
>>> One problem is a number of people wanted to steal the code and use in
>>> a paid application, so the copyright is some what a requirement.
>>
>> In that case, why is it under a BSD'ish license instead of something
>> like GPL that's designed to prevent it in the first place? Might be too
>> late to change it by now, just wondering.
>
> DPDK is BSD, so you can not use a GPL application with DPDK (I think)

Well I sure hope the license is not chosen by that assumption. Why 
assume when you can trivially check, eg:
http://www.gnu.org/licenses/license-list.html

DPDK itself is under the very lax 3-clause BSD license which is 
compatible with the GPL. The 4-clause "advertising license" used by 
pktgen is not. But its not the license I'm complaining about.

> anyway I can try to speed you the screens, but does it really matter
> as these are only at startup and I normally leave pktgen running for
> long periods of time. The extra time at the start does not seem to
> be a big issue, right?

We wouldn't be discussing this if it was not an issue. It is offensive 
enough to turn away both users and contributors, and merely speeding up 
a bit is not going to make it a whole lot better.

As I (and now others as well) already suggested changing it to a one 
line printout is what would make worlds of difference while still 
complying with the license AFAICT. The license text requires printing 
out the copyright notice, it does not say anything about rendering it in 
full-screen ascii-art, or printing out the entire license.

	- Panu -

Re: [dpdk-dev] [PKTGEN] fixing weird termio issues that complicate debugging

[Wiles, Keith]

On 1/22/16, 1:45 AM, "Panu Matilainen" <pmatilai@redhat.com> wrote:

>On 01/21/2016 05:03 PM, Wiles, Keith wrote:
>> On 1/21/16, 2:46 AM, "Panu Matilainen" <pmatilai@redhat.com> wrote:
>>
>>> On 01/20/2016 06:26 PM, Wiles, Keith wrote:
>>>> On 1/20/16, 12:32 AM, "dev on behalf of Matthew Hall" <dev-bounces@dpdk.org on behalf of mhall@mhcomputing.net> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> Since the pktgen code is reindented I am finding time to read through it
>>>>> and experiment and see if I can get it working.
>>>>>
>>>>> I have issues with the init process of pktgen. It is difficult to debug
>>>>> it because the init code does a lot of very scary stuff to the terminal
>>>>> control / TTY device at inconvenient times in an inconvenient order, and
>>>>> in the process damages the debug output and damages the screen of your
>>>>> GDB without doing weird things to run GDB on a different TTY.
>>>>>
>>>>> Of course I am willing to contribute patches and not just complain, but
>>>>> first I need some help to follow what is going on.
>>>>>
>>>>> Here is the problematic call-flow with some explanation what went wrong
>>>>> trying it on some community machines outside of its original environment:
>>>>>
>>>>> 1) it calls printf("\n%s %s\n", wr_copyright_msg(), wr_powered_by());
>>>>> which dumps tons of weird boilerplate of licenses, copyrights, code
>>>>> creator, etc.
>>>>>
>>>>> It is open source and everybody that matters already knows who coded it,
>>>>> so is this stuff really that important? This gets in the way when you
>>>>> are trying to work on it and I just have to comment it out.
>>>>
>>>> One problem is a number of people wanted to steal the code and use in
>>>> a paid application, so the copyright is some what a requirement.
>>>
>>> In that case, why is it under a BSD'ish license instead of something
>>> like GPL that's designed to prevent it in the first place? Might be too
>>> late to change it by now, just wondering.
>>
>> DPDK is BSD, so you can not use a GPL application with DPDK (I think)
>
>Well I sure hope the license is not chosen by that assumption. Why 
>assume when you can trivially check, eg:
>http://www.gnu.org/licenses/license-list.html
>
>DPDK itself is under the very lax 3-clause BSD license which is 
>compatible with the GPL. The 4-clause "advertising license" used by 
>pktgen is not. But its not the license I'm complaining about.
>
>> anyway I can try to speed you the screens, but does it really matter
>> as these are only at startup and I normally leave pktgen running for
>> long periods of time. The extra time at the start does not seem to
>> be a big issue, right?
>
>We wouldn't be discussing this if it was not an issue. It is offensive 
>enough to turn away both users and contributors, and merely speeding up 
>a bit is not going to make it a whole lot better.
>
>As I (and now others as well) already suggested changing it to a one 
>line printout is what would make worlds of difference while still 
>complying with the license AFAICT. The license text requires printing 
>out the copyright notice, it does not say anything about rendering it in 
>full-screen ascii-art, or printing out the entire license.

Thank you Panu for your input, I will think about.

>
>	- Panu -
>


Regards,
Keith

Re: [dpdk-dev] [PKTGEN] fixing weird termio issues that complicate debugging

[Panu Matilainen]

On 01/23/2016 04:22 AM, Wiles, Keith wrote:
> On 1/22/16, 1:45 AM, "Panu Matilainen" <pmatilai@redhat.com> wrote:
>> We wouldn't be discussing this if it was not an issue. It is offensive
>> enough to turn away both users and contributors, and merely speeding up
>> a bit is not going to make it a whole lot better.
>>
>> As I (and now others as well) already suggested changing it to a one
>> line printout is what would make worlds of difference while still
>> complying with the license AFAICT. The license text requires printing
>> out the copyright notice, it does not say anything about rendering it in
>> full-screen ascii-art, or printing out the entire license.
>
> Thank you Panu for your input, I will think about.

Looking at pktgen 2.9.12 and seeing all the ugly startup goo is now 
gone, its my turn to

THANK YOU!

	- Panu -