[vpp-dev] Masking IP addresses for HQoS

[Usama Ahmad]

Hi,
I want to ask if I can somehow classify a single IP address and then apply 
desired QoS abilities. For what I understand I can only apply a 64 bit mask 
with a window of 4096 buckets.
I’m following this 
guide and 
trying to use pktfield command.
Can somebody guide me how can I (if possible) match only 1 IP address? Or how 
can I use 64 bit mask to classify IP address fields.

Thanks,
Usama

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11377): https://lists.fd.io/g/vpp-dev/message/11377
Mute This Topic: https://lists.fd.io/mt/28291444/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Request: please add "real" pcap ability #vpp

[Jerome Tollet via Lists.Fd.Io]

I tried in the past and that was working fine.
Jerome

De : Brian Dickson 
Date : vendredi 23 novembre 2018 à 07:44
À : Jerome Tollet 
Cc : "vpp-dev@lists.fd.io" 
Objet : Re: [vpp-dev] Request: please add "real" pcap ability #vpp


On Thu, Nov 22, 2018 at 8:18 AM Jerome Tollet (jtollet) 
mailto:jtol...@cisco.com>> wrote:
Hi Peter,

(It's actually Brian, BTW.)

Did you try creating a pg interface and spanning packet from your port to this 
interface?

I didn't, there wasn't a lot of documentation that would have pointed in that 
direction.

But, I will, thanks for the suggestion.

Brian

Jerome

De : mailto:vpp-dev@lists.fd.io>> au nom de 
"brian.peter.dick...@gmail.com" 
mailto:brian.peter.dick...@gmail.com>>
Date : jeudi 22 novembre 2018 à 00:58
À : "vpp-dev@lists.fd.io" 
mailto:vpp-dev@lists.fd.io>>
Objet : [vpp-dev] Request: please add "real" pcap ability #vpp

Hi, dev folks,

Apologies for my first message being kind of demanding.

However, I think this is a reasonable request.

What I am interested in, and I think this is likely to be a fairly universal 
desire, is the ability to properly integrate some kind of pcap packet capture 
to the full VPP graph.

The current available mechanisms (pcap drop trace and pcap tx trace) do not 
apply to packets that are only "handled" by the host in question, i.e. neither 
originate or terminate on the local host.

In particular, I'm interested in something that can run on a bare metal host 
and, presuming sufficient resources can be given to it (cores, memory, etc), do 
packet capture at line rate.

Thus, any restriction ("run it on a VM") is not adequate.

Given that there is already stuff for handling the pcap file already (in 
vnet/unix IIRC), this should not be a lot of work.

There are two use cases I have:
• debugging data plane stuff on a vpp-based router (i.e. using the 
vppsb netlink and router projects)
• packet capture at line rate (a vpp host that only listens/drops 
traffic, incidental to the packet capture, i.e. a single-purpose host, 
bypassing kernel/driver limitations, to take all ethernet traffic on a port and 
stuff it into a pcap file.)
oNB: for scaling purposes, it is reasonable to implement the pcap captures 
using RSS/RFS to multiple cores and having each core be a thread doing pcap 
file writing; how that would be put into the "vpp graph" might be a little less 
than trivial, but should be straightforward, IMHO)
Thanks in advance.

Brian Dickson

P.S. There is a SERIOUS lack of useful documentation on how to actually do 
this, as a potential ad-hoc contributor. Not sure if you guys have gotten this 
feedback from anyone else.
P.P.S. I'm using 18.07 because that is the last version that builds alongside 
the vppsb netlink and router plugins.
P.P.P.S. Even getting 18.07 and vppsb to build was a nightmare. You should try 
doing this from scratch, i.e. put yourselves in the shoes of someone who just 
discovered vpp...
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11376): https://lists.fd.io/g/vpp-dev/message/11376
Mute This Topic: https://lists.fd.io/mt/28282785/21656
Mute #vpp: https://lists.fd.io/mk?hashtag=vpp=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Request: please add "real" pcap ability #vpp

[Brian Dickson]

On Thu, Nov 22, 2018 at 8:18 AM Jerome Tollet (jtollet) 
wrote:

> Hi Peter,
>

(It's actually Brian, BTW.)


> Did you try creating a pg interface and spanning packet from your port to
> this interface?
>

I didn't, there wasn't a lot of documentation that would have pointed in
that direction.

But, I will, thanks for the suggestion.

Brian


> Jerome
>
>
>
> *De : * au nom de "brian.peter.dick...@gmail.com" <
> brian.peter.dick...@gmail.com>
> *Date : *jeudi 22 novembre 2018 à 00:58
> *À : *"vpp-dev@lists.fd.io" 
> *Objet : *[vpp-dev] Request: please add "real" pcap ability #vpp
>
>
>
> Hi, dev folks,
>
> Apologies for my first message being kind of demanding.
>
> However, I think this is a reasonable request.
>
> What I am interested in, and I think this is likely to be a fairly
> universal desire, is the ability to properly integrate some kind of pcap
> packet capture to the full VPP graph.
>
> The current available mechanisms (pcap drop trace and pcap tx trace) do
> not apply to packets that are only "handled" by the host in question, i.e.
> neither originate or terminate on the local host.
>
> In particular, I'm interested in something that can run on a bare metal
> host and, presuming sufficient resources can be given to it (cores, memory,
> etc), do packet capture at line rate.
>
> Thus, any restriction ("run it on a VM") is not adequate.
>
> Given that there is already stuff for handling the pcap file already (in
> vnet/unix IIRC), this should not be a lot of work.
>
> There are two use cases I have:
>
> · debugging data plane stuff on a vpp-based router (i.e. using
> the vppsb netlink and router projects)
>
> · packet capture at line rate (a vpp host that only listens/drops
> traffic, incidental to the packet capture, i.e. a single-purpose host,
> bypassing kernel/driver limitations, to take all ethernet traffic on a port
> and stuff it into a pcap file.)
>
> oNB: for scaling purposes, it is reasonable to implement the pcap
> captures using RSS/RFS to multiple cores and having each core be a thread
> doing pcap file writing; how that would be put into the "vpp graph" might
> be a little less than trivial, but should be straightforward, IMHO)
>
> Thanks in advance.
>
> Brian Dickson
>
> P.S. There is a SERIOUS lack of useful documentation on how to actually do
> this, as a potential ad-hoc contributor. Not sure if you guys have gotten
> this feedback from anyone else.
> P.P.S. I'm using 18.07 because that is the last version that builds
> alongside the vppsb netlink and router plugins.
> P.P.P.S. Even getting 18.07 and vppsb to build was a nightmare. You should
> try doing this from scratch, i.e. put yourselves in the shoes of someone
> who just discovered vpp...
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11374): https://lists.fd.io/g/vpp-dev/message/11374
Mute This Topic: https://lists.fd.io/mt/28282785/21656
Mute #vpp: https://lists.fd.io/mk?hashtag=vpp=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Request: please add "real" pcap ability #vpp

[Jerome Tollet via Lists.Fd.Io]

Hi Peter,
Did you try creating a pg interface and spanning packet from your port to this 
interface?
Jerome

De :  au nom de "brian.peter.dick...@gmail.com" 

Date : jeudi 22 novembre 2018 à 00:58
À : "vpp-dev@lists.fd.io" 
Objet : [vpp-dev] Request: please add "real" pcap ability #vpp

Hi, dev folks,

Apologies for my first message being kind of demanding.

However, I think this is a reasonable request.

What I am interested in, and I think this is likely to be a fairly universal 
desire, is the ability to properly integrate some kind of pcap packet capture 
to the full VPP graph.

The current available mechanisms (pcap drop trace and pcap tx trace) do not 
apply to packets that are only "handled" by the host in question, i.e. neither 
originate or terminate on the local host.

In particular, I'm interested in something that can run on a bare metal host 
and, presuming sufficient resources can be given to it (cores, memory, etc), do 
packet capture at line rate.

Thus, any restriction ("run it on a VM") is not adequate.

Given that there is already stuff for handling the pcap file already (in 
vnet/unix IIRC), this should not be a lot of work.

There are two use cases I have:
· debugging data plane stuff on a vpp-based router (i.e. using the 
vppsb netlink and router projects)
· packet capture at line rate (a vpp host that only listens/drops 
traffic, incidental to the packet capture, i.e. a single-purpose host, 
bypassing kernel/driver limitations, to take all ethernet traffic on a port and 
stuff it into a pcap file.)
oNB: for scaling purposes, it is reasonable to implement the pcap captures 
using RSS/RFS to multiple cores and having each core be a thread doing pcap 
file writing; how that would be put into the "vpp graph" might be a little less 
than trivial, but should be straightforward, IMHO)
Thanks in advance.

Brian Dickson

P.S. There is a SERIOUS lack of useful documentation on how to actually do 
this, as a potential ad-hoc contributor. Not sure if you guys have gotten this 
feedback from anyone else.
P.P.S. I'm using 18.07 because that is the last version that builds alongside 
the vppsb netlink and router plugins.
P.P.P.S. Even getting 18.07 and vppsb to build was a nightmare. You should try 
doing this from scratch, i.e. put yourselves in the shoes of someone who just 
discovered vpp...
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11373): https://lists.fd.io/g/vpp-dev/message/11373
Mute This Topic: https://lists.fd.io/mt/28282785/21656
Mute #vpp: https://lists.fd.io/mk?hashtag=vpp=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] vppcom: why __vcl_worker_index is thread local? #vpp

[at . manuel]

Hello all,
Having that index in the thread context is breaking run-time of multi-threaded 
applications. Most of them accept connections in a main loop and process data 
in a thread by passing the socket descriptor.
I understand that there is no data protections across the interface 
library..but, are there any other reasons, that I might be missing, for that?

Thanks in advance.
Manuel
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11372): https://lists.fd.io/g/vpp-dev/message/11372
Mute This Topic: https://lists.fd.io/mt/28286895/21656
Mute #vpp: https://lists.fd.io/mk?hashtag=vpp=1480452
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Enabling unit tests in VPP job for ARM and make test failures

[Juraj Linkeš]

Hi Folks,

There's another approach we could try and that is we could exclude the 
currently failing tests and run just what passes so that we can prevent other 
failures creeping up on us. Of course, we would remove the exclusions when the 
failures are fixed.

I've put together a patch that introduces test blacklisting: 
https://gerrit.fd.io/r/#/c/16118/

I've also updated the corresponding CI patch 
(https://gerrit.fd.io/r/#/c/15251/) with the blacklist.

What do you thing about this approach?

Thanks,
Juraj

From: Juraj Linkeš [mailto:juraj.lin...@pantheon.tech]
Sent: Friday, November 16, 2018 4:58 PM
To: vpp-dev@lists.fd.io
Cc: csit-dev 
Subject: [vpp-dev] Enabling unit tests in VPP job for ARM and make test failures

Hi vpp-dev,

As many of you already know, we tried enabling unit tests in ARM VPP jobs the 
last release cycle, but we only managed to fix all make test failures during 
release procedures and we agreed that enabling it would be better after 1810 is 
released.

Enabling the unit testing (i.e. running full make verify) when there are 
failures is, in my opinion, a fool's errand. If people see consistent failures 
that are not related to their patches, they're much less likely to investigate 
whether this time there's really a legitimate failure and more likely to just 
ignore the job since it's just not working. That means we'll really need to 
iron out all of the failures before doing anything else.

So let's talk about the failures. There were new failures in master almost 
immediately after the release and these are seemingly also reproducible on x86 
(although I have no idea why they don't show up in CI):

*VPP-1475 - IP4 random reassembly 
failure

*VPP-1476 - L2fib missing packets

Not long after these issues, new issues cropped up. At one point even the 
sanity test didn't pass (that was addressed by 
https://gerrit.fd.io/r/#/c/15841/, thanks, Neale!) and there was an issue with 
sessions tests (fixed by https://gerrit.fd.io/r/#/c/15947/, thanks, Florin!). 
But there are still more issues that need our attention:

*VPP-1490 - Looks like traffic 
isn't working on ARM on Ubuntu1604

*VPP-1491 - GBD l2 endpoint 
learning. The tests actually pass with the debug build

*VPP-1497 - Parallel test execution 
on ARM produced many more failures. I haven't investigated this much yet

*And there is a new failure in a CDP test, this is not in Jira yet 
(there are some problems with accessing stuff in lab, curses!)

This very much seems like a game of whack-a-mole - we fix a few issues and new 
appear right away. This might suggest that the current approach of me finding 
issues on an ARM server and then notifying vpp-dev might not be ideal if we 
want to enable unit testing in 1901 (and we really do! :)). Or maybe this is 
not the right time to enable testing and we should focus on it more a few weeks 
before release? What's the best way to ensure that we'll get testing in as soon 
as possible?

In any case, we'll need a lot of help from you. I urge everyone (or at least a 
few key people) to get access to the FD.io lab (you'll need a GPG key that Ed 
Warnicke or some other trusted anchor will sign and then request access using 
the fd.io helpdesk) so that you can use our hardware we're reserved for this 
purpose. We could also always debug via a call, but that's just not efficient 
and you'll need some ARM hardware for development anyway (or to just fix issues 
that show up in verify jobs).

When it comes to the individual issues, any feedback is appreciated, like just 
the author acknowledging the issue and maybe adding whether they have time to 
look at it or what more information they need.

Let's make VPP development much more smoother for ARM ASAP, guys. :)

Thanks,
Juraj
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11371): https://lists.fd.io/g/vpp-dev/message/11371
Mute This Topic: https://lists.fd.io/mt/28167603/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Difference between PRE_INPUT and INPUT nodes

[Prashant Upadhyaya]

Thanks Dave !
I got it working with your suggestions :)

Regards
-Prashant

On Thu, Nov 22, 2018 at 7:31 PM Dave Barach (dbarach)  wrote:
>
> Try setting the node state to VLIB_NODE_STATE_DISABLED on the main thread:
>
> Vlib_node_state_state (vlib_mains[0] or _global_main, ...):
>
>
> /** \brief Set node dispatch state.
>  @param vm vlib_main_t pointer, varies by thread
>  @param node_index index of the node
>  @param new_state new state for node, see vlib_node_state_t
> */
> void vlib_node_set_state (vlib_main_t * vm, u32 node_index, vlib_node_state_t 
> new_state)
>
> -Original Message-
> From: Prashant Upadhyaya 
> Sent: Thursday, November 22, 2018 8:53 AM
> To: Dave Barach (dbarach) 
> Cc: vpp-dev@lists.fd.io
> Subject: Re: [vpp-dev] Difference between PRE_INPUT and INPUT nodes
>
> Thanks Dave.
> I used the VLIB_NODE_TYPE_INPUT, but I now observe that, in presence of 
> worker threads, my main thread is going to 100 % cpu utilization as well.
> Without my new node, the main thread does not go to 100 % cpu utilization.
> I want the polling to happen only in worker threads (or the main thread if 
> there are no workers) Can I do something at the runtime to achieve that ?
>
> Regards
> -Prashant
>
> On Thu, Nov 22, 2018 at 7:02 PM Dave Barach (dbarach)  
> wrote:
> >
> > Use VLIB_NODE_TYPE_INPUT. Pre-input nodes - of which there is one - exist 
> > to make sure that a certain epoll(...) call happens at the top of the loop.
> >
> > D.
> >
> > -Original Message-
> > From: vpp-dev@lists.fd.io  On Behalf Of Prashant
> > Upadhyaya
> > Sent: Thursday, November 22, 2018 7:41 AM
> > To: vpp-dev@lists.fd.io
> > Subject: [vpp-dev] Difference between PRE_INPUT and INPUT nodes
> >
> > Hi,
> >
> > What is the difference between --
> > .type = VLIB_NODE_TYPE_PRE_INPUT
> > and
> > .type = VLIB_NODE_TYPE_INPUT
> >
> > when the --
> > .state = VLIB_NODE_STATE_POLLING
> >
> > Typically when should the PRE_INPUT be used and when the INPUT, would 
> > appreciate any advice on this. My usecase needs to do a high speed polling.
> >
> > Regards
> > -Prashant
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11369): https://lists.fd.io/g/vpp-dev/message/11369
Mute This Topic: https://lists.fd.io/mt/28286049/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Difference between PRE_INPUT and INPUT nodes

[Dave Barach via Lists.Fd.Io]

Try setting the node state to VLIB_NODE_STATE_DISABLED on the main thread:

Vlib_node_state_state (vlib_mains[0] or _global_main, ...):


/** \brief Set node dispatch state.
 @param vm vlib_main_t pointer, varies by thread
 @param node_index index of the node
 @param new_state new state for node, see vlib_node_state_t
*/
void vlib_node_set_state (vlib_main_t * vm, u32 node_index, vlib_node_state_t 
new_state)

-Original Message-
From: Prashant Upadhyaya  
Sent: Thursday, November 22, 2018 8:53 AM
To: Dave Barach (dbarach) 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] Difference between PRE_INPUT and INPUT nodes

Thanks Dave.
I used the VLIB_NODE_TYPE_INPUT, but I now observe that, in presence of worker 
threads, my main thread is going to 100 % cpu utilization as well.
Without my new node, the main thread does not go to 100 % cpu utilization.
I want the polling to happen only in worker threads (or the main thread if 
there are no workers) Can I do something at the runtime to achieve that ?

Regards
-Prashant

On Thu, Nov 22, 2018 at 7:02 PM Dave Barach (dbarach)  wrote:
>
> Use VLIB_NODE_TYPE_INPUT. Pre-input nodes - of which there is one - exist to 
> make sure that a certain epoll(...) call happens at the top of the loop.
>
> D.
>
> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of Prashant 
> Upadhyaya
> Sent: Thursday, November 22, 2018 7:41 AM
> To: vpp-dev@lists.fd.io
> Subject: [vpp-dev] Difference between PRE_INPUT and INPUT nodes
>
> Hi,
>
> What is the difference between --
> .type = VLIB_NODE_TYPE_PRE_INPUT
> and
> .type = VLIB_NODE_TYPE_INPUT
>
> when the --
> .state = VLIB_NODE_STATE_POLLING
>
> Typically when should the PRE_INPUT be used and when the INPUT, would 
> appreciate any advice on this. My usecase needs to do a high speed polling.
>
> Regards
> -Prashant
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11368): https://lists.fd.io/g/vpp-dev/message/11368
Mute This Topic: https://lists.fd.io/mt/28286049/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Difference between PRE_INPUT and INPUT nodes

[Prashant Upadhyaya]

Thanks Dave.
I used the VLIB_NODE_TYPE_INPUT, but I now observe that, in presence
of worker threads, my main thread is going to 100 % cpu utilization as
well.
Without my new node, the main thread does not go to 100 % cpu utilization.
I want the polling to happen only in worker threads (or the main
thread if there are no workers)
Can I do something at the runtime to achieve that ?

Regards
-Prashant

On Thu, Nov 22, 2018 at 7:02 PM Dave Barach (dbarach)  wrote:
>
> Use VLIB_NODE_TYPE_INPUT. Pre-input nodes - of which there is one - exist to 
> make sure that a certain epoll(...) call happens at the top of the loop.
>
> D.
>
> -Original Message-
> From: vpp-dev@lists.fd.io  On Behalf Of Prashant 
> Upadhyaya
> Sent: Thursday, November 22, 2018 7:41 AM
> To: vpp-dev@lists.fd.io
> Subject: [vpp-dev] Difference between PRE_INPUT and INPUT nodes
>
> Hi,
>
> What is the difference between --
> .type = VLIB_NODE_TYPE_PRE_INPUT
> and
> .type = VLIB_NODE_TYPE_INPUT
>
> when the --
> .state = VLIB_NODE_STATE_POLLING
>
> Typically when should the PRE_INPUT be used and when the INPUT, would 
> appreciate any advice on this. My usecase needs to do a high speed polling.
>
> Regards
> -Prashant
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11367): https://lists.fd.io/g/vpp-dev/message/11367
Mute This Topic: https://lists.fd.io/mt/28286049/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Difference between PRE_INPUT and INPUT nodes

[Dave Barach via Lists.Fd.Io]

Use VLIB_NODE_TYPE_INPUT. Pre-input nodes - of which there is one - exist to 
make sure that a certain epoll(...) call happens at the top of the loop.

D.

-Original Message-
From: vpp-dev@lists.fd.io  On Behalf Of Prashant Upadhyaya
Sent: Thursday, November 22, 2018 7:41 AM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] Difference between PRE_INPUT and INPUT nodes

Hi,

What is the difference between --
.type = VLIB_NODE_TYPE_PRE_INPUT
and
.type = VLIB_NODE_TYPE_INPUT

when the --
.state = VLIB_NODE_STATE_POLLING

Typically when should the PRE_INPUT be used and when the INPUT, would 
appreciate any advice on this. My usecase needs to do a high speed polling.

Regards
-Prashant
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11365): https://lists.fd.io/g/vpp-dev/message/11365
Mute This Topic: https://lists.fd.io/mt/28286049/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: 答复: [vpp-dev] about sctp

[Marco Varlese]

Dear Liu,
The reason why I asked you to take a look at the "test_sctp.py" is to see how
things are setup and execute the exact steps in the CLI. You'll see things work.
You cannot remove the MTU code because that's used to initialize the PMTU and
calculate initially the MSS to be sent to the other peer.

Cheers,Marco
On Wed, 2018-11-21 at 01:50 +, Liu Daolin (刘道林) wrote:
> Hi Marco,
>  
> Thanks for your reply.
>  
> Actually I'm trying to read the sctp code recently to want to know how it
> works. My requirement is very simply. I need to run sctp server based on vpp
> on one VM, and run sctp client without vpp (I have this now) on the other VM.
> As my
>  below email, there will be aborted (core dumped), and I found the place
> yesterday, but I don’t know the root reason. You can see below picture:
>  
> 
>  
> The sw_if_index is -1, so crashed when get mtu. Maybe I miss something? When I
> run actually is CLI command from echo_server.c. As you mentioned, if I run
> test_sctp.py, it will work fine? My requirement is only C language as it will
> merged
>  some other code, so I don’t like to run it with python.
>  
> Yesterday, I also try to remove this mtu code, and the crash was disappeared
> although the sw_if_index is still -1, and then I start sctp client on the
> other VM to send INIT, but the server with vpp seemed be dead (no crash but
> cannot
>  enter any command, seemed dead loop).
>  
> Anyway, I think it's better to try CLI "test echo server" in your side and
> find and fix all issues visually.
>  
>  
>  
>  
>  
> Best regards
> 刘道林 (Daolin Liu)
> T大连市共进科技有限公司
> DALIAN GONGJIN TECHNOLOGY CO.,LTD
> 中国大连市高新园区软件园路1A-4-24层
> Floor 24th, 1A-4 Software Park Road, Hi-tech Zone, Dalian, Liaoning, China
> 直线(TEL)：(86-411)39996705  
> 分机(EXT)：76824
> 手机(Mobile)：(86)13704090959
>  
> -邮件原件-
> 
> 发件人: Marco Varlese [mailto:mvarl...@suse.de]
> 
> 
> 发送时间: 2018年11月21日 1:06
> 
> 收件人: Liu Daolin (刘道林); vpp-dev@lists.fd.io
> 
> 主题: Re: [vpp-dev] about sctp
>  
> Hi,
>  
> On Tue, 2018-11-20 at 02:50 +, Liu Daolin (刘道林) wrote:
> > Hi,
> >  
> > I encountered below Aborted (core dumped) issue:
> >  
> > 
> >  
> > When I run "test echo server uri", it's ok for tcp, but crashed immediately
> > for sctp.
> >  
> > Please try this in your side and give me advice. I use 18.10. Thanks!
> Can you please try to run "make test TEST=test_sctp"?
> >  
> >  
> > Best regards
> > 刘道林 (Daolin Liu)
> > T大连市共进科技有限公司
> > DALIAN GONGJIN TECHNOLOGY CO.,LTD
> > 中国大连市高新园区软件园路1A-4-24层
> > Floor 24th, 1A-4 Software Park Road, Hi-tech Zone, Dalian, Liaoning, China
> > 直线(TEL)：(86-411)39996705  
> 分机(EXT)：76824
> > 手机(Mobile)：(86)13704090959
> >  
> > 发件人: Liu Daolin (刘道林)
> 
> > 发送时间: 2018年11月19日 19:23
> > 收件人: 'vpp-dev@lists.fd.io'
> > 主题: about sctp
> >  
> > Hi,
> >  
> > I'd like to know some information about sctp.
> >  
> > Is this fully functional? Or just partly? 
> There are missing pieces to the SCTP implementations. 
>  
> > Actually, I want to try simply with CLI to verify sctp basic functions now.
> > But it seems that there is no CLI, and the binary APIs are also imperfect.
> What do you actually mean by imperfect? Any input (e.g. patch submission)
> would
> be greatly appreciated!
> >  
> > Do you have any plan in the next release? Including the sample test.
> I am planning to create some JIRA ticket(s) so that people can see what's
> missing and contribute if they like. Would you be interested?
>  
> >  
> > Best regards
> > 刘道林 (Daolin Liu)
> > T大连市共进科技有限公司
> > DALIAN GONGJIN TECHNOLOGY CO.,LTD
> > 中国大连市高新园区软件园路1A-4-24层
> > Floor 24th, 1A-4 Software Park Road, Hi-tech Zone, Dalian, Liaoning, China
> > 直线(TEL)：(86-411)39996705  
> 分机(EXT)：76824
> > 手机(Mobile)：(86)13704090959
> >  
> >
> 本电子邮件（包括任何的附件）为本公司保密文件。本文件仅仅可为以上指定的收件人或公司使用，如果阁下非电子邮件所指定之收件人，那么阁下对该邮件部分或全部的泄漏、
> >
> 阅览、复印、变更、散布或对邮件内容的使用都是被严格禁止的。如果阁下接收了该错误传送的电子邮件，敬请阁下通过回复该邮件的方式立即通知寄件人，同时删除你所接收到
> > 的文本。 This e-mail may contain confidential and/or privileged information. If
> > you are not the intended recipient (or have received this e-mail in error)
> > please notify the sender immediately and destroy this e-mail. Any
> unauthorized
> > copying, disclosure or distribution of the material in this e-mail is
> strictly
> > forbidden.
> > -=-=-=-=-=-=-=-=-=-=-=-
> > Links: You receive all messages sent to this group.
> > 
> > View/Reply Online (#11334): https://lists.fd.io/g/vpp-dev/message/11334
> > Mute This Topic: https://lists.fd.io/mt/28240674/675056
> > Group Owner: vpp-dev+ow...@lists.fd.io
> > Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [mvarl...@suse.de]
> > -=-=-=-=-=-=-=-=-=-=-=-
> 
> 
> 本电子邮件（包括任何的附件）为本公司保密文件。本文件仅仅可为以上指定的收件人或公司使用，如果阁下非电子邮件所指定之收件人，那么阁下对该邮件部分或全部的泄漏、
> 阅览、复印、变更、散布或对邮件内容的使用都是被严格禁止的。如果阁下接收了该错误传送的电子邮件，敬请阁下通过回复该邮件的方式立即通知寄件人，同时删除你所接收到
> 的文本。 This e-mail may contain confidential and/or privileged information. If
> you are not the intended
>  recipient (or have received this e-mail in error) please notify the 

[vpp-dev] Difference between PRE_INPUT and INPUT nodes

[Prashant Upadhyaya]

Hi,

What is the difference between --
.type = VLIB_NODE_TYPE_PRE_INPUT
and
.type = VLIB_NODE_TYPE_INPUT

when the --
.state = VLIB_NODE_STATE_POLLING

Typically when should the PRE_INPUT be used and when the INPUT, would
appreciate any advice on this. My usecase needs to do a high speed
polling.

Regards
-Prashant
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11363): https://lists.fd.io/g/vpp-dev/message/11363
Mute This Topic: https://lists.fd.io/mt/28286049/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [vpp-dev] Muliticore Performance test

[kyunghwan kim]

Korian

While modifying num-mbufs(num-mbufs 128000) and performing Performance
tests,
I also faced the same Bug.
We are testing bi-direction with 40Gbps.
"One port Rx frame is 1"

Do you have any other doubts?


vpp# show interface
  Name   IdxState  MTU (L3/IP4/IP6/MPLS)
Counter  Count
FortyGigabitEthernet3/0/0 1  up  9000/0/0/0 rx
packets 863402200
rx
bytes107061872736
tx
packets 431639482
tx
bytes 53523295686

drops  52392

ip4863402199

rx-miss  1591588
FortyGigabitEthernet4/0/0 2  up  9000/0/0/0 rx
packets 1
rx
bytes  60
tx
packets 431710328
tx
bytes 53532080590

drops  1
local00 down  0/0/0/0
vpp# show dpdk buffer
name="dpdk_mbuf_pool_socket0"  available =  110565 allocated =   17369
total =  127934
name="dpdk_mbuf_pool_socket1"  available =  128000 allocated =   0
total =  128000
vpp#

Regards,
Kyunghwan Kim

2018년 11월 22일 (목) 오전 11:42, kyunghwan kim 님이 작성:

> Korian,
>
> Thanks for your reply,
> I solved the problem.
>
> Previously num-mbufs is the default,
> vpp # show dpdk buffer
> name = "dpdk_mbuf_pool_socket 0" available = 7938 allocated = 8446 total =
> 16384
> name = "dpdk_mbuf_pool_socket 1" available = 16384 allocated = 0 total =
> 16384
> vpp #
>
> Increase num-mbufs in startup.conf
> vpp # show dpdk buffer
> name = "dpdk_mbuf_pool_socket 0" available = 119552 allocated = 8448 total
> = 128000
> name = "dpdk_mbuf_pool_socket 1" available = 128000 allocated = 0 total =
> 128000
> vpp #
>
> When packets are flowed at 40 Gbps / 64 bytes
> vpp # show dpdk buffer
> name = "dpdk_mbuf_pool_socket 0" available = 102069 allocated = 25776
> total = 127845
> name = "dpdk_mbuf_pool_socket 1" available = 128000 allocated = 0 total =
> 128000
> vpp #
>
> I found out that buffer is missing.
> Thank you so much.
>
> Regards,
> Kyunghwan Kim
>
>
> 2018년 11월 21일 (수) 오후 9:29, korian edeline 님이 작성:
>
>> Hello,
>>
>> On 11/21/18 1:10 PM, kyunghwan kim wrote:
>> > rx-no-buf  1128129034176
>>
>>
>> You should be able to fix this particular problem by increasing
>> num-mbufs in startup.conf, you can check the allocation with vpp# sh
>> dpdk buffer
>>
>>
>> > rx-miss951486596
>>
>> This is probably another problem.
>>
>>
>> Cheers,
>>
>> Korian
>>
>>
>
> --
> 
> キム、キョンファン
> Tel : 080-3600-2306
> E-mail : gpi...@gmail.com
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
>
> View/Reply Online (#11360): https://lists.fd.io/g/vpp-dev/message/11360
> Mute This Topic: https://lists.fd.io/mt/28276317/1512670
> Group Owner: vpp-dev+ow...@lists.fd.io
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [gpi...@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>


-- 

キム、キョンファン
Tel : 080-3600-2306
E-mail : gpi...@gmail.com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#11362): https://lists.fd.io/g/vpp-dev/message/11362
Mute This Topic: https://lists.fd.io/mt/28276317/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] Regarding page table address NULL in dpdk_pool_create

[Alok Makhariya]

Hi

I have a situation where in some scenarios when VPP is restarted after a crash, 
the VPP which is coming up itself crashes with the following backtrace.
This does not happen always. Any hints on what could cause this would be 
appreciated.

Backtrace

(gdb) bt
#0  0x2b688139c207 in raise () from /lib64/libc.so.6
#1  0x2b688139d8f8 in abort () from /lib64/libc.so.6
#2  0x00405f7e in os_exit (code=code@entry=1) at 
/bfs-build/build-area.49/builds/LinuxNBngp_7.X_RH7/2018-11-16-0505/third-party/vpp/vpp_1801/build-data/../src/vpp/vnet/main.c:292
#3  0x2b687f4b09d7 in unix_signal_handler (signum=, 
si=, uc=)
at 
/bfs-build/build-area.49/builds/LinuxNBngp_7.X_RH7/2018-11-16-0505/third-party/vpp/vpp_1801/build-data/../src/vlib/unix/main.c:120
#4  
#5  rte_mempool_populate_iova_tab (mp=mp@entry=0x1098fbec0, 
vaddr=0x2ac0 "", iova=0x0, pg_num=, pg_shift=, free_cb=free_cb@entry=0x0, opaque=opaque@entry=0x0)
at 
/bfs-build/build-area.49/builds/LinuxNBngp_7.X_RH7/2018-11-16-0505/third-party/vpp/vpp_1801/build-root/build-vpp-native/dpdk/dpdk-stable-17.11.4/lib/librte_mempool/rte_mempool.c:486
#6  0x2b6b0212a373 in dpdk_pool_create (vm=vm@entry=0x2b687f6cb260 
, pool_name=pool_name@entry=0x2b6883a0d924 
"dpdk_mbuf_pool_socket0", elt_size=elt_size@entry=2432, 
num_elts=num_elts@entry=50,
pool_priv_size=pool_priv_size@entry=6, cache_size=cache_size@entry=512, 
numa=numa@entry=0 '\000', _mp=_mp@entry=0x2b6884266c68, 
pri=pri@entry=0x2b6884266c5f "")
at 
/bfs-build/build-area.49/builds/LinuxNBngp_7.X_RH7/2018-11-16-0505/third-party/vpp/vpp_1801/build-data/../src/plugins/dpdk/buffer.c:498
#7  0x2b6b0212a470 in dpdk_buffer_pool_create (vm=vm@entry=0x2b687f6cb260 
, num_mbufs=50, socket_id=0)
at 
/bfs-build/build-area.49/builds/LinuxNBngp_7.X_RH7/2018-11-16-0505/third-party/vpp/vpp_1801/build-data/../src/plugins/dpdk/buffer.c:537
#8  0x2b6b02144861 in dpdk_config (vm=, input=)
at 
/bfs-build/build-area.49/builds/LinuxNBngp_7.X_RH7/2018-11-16-0505/third-party/vpp/vpp_1801/build-data/../src/plugins/dpdk/device/init.c:1288
#9  0x2b687f4715ad in vlib_call_all_config_functions (vm=, 
input=input@entry=0x2b6884266fa0, is_early=is_early@entry=0)
at 
/bfs-build/build-area.49/builds/LinuxNBngp_7.X_RH7/2018-11-16-0505/third-party/vpp/vpp_1801/build-data/../src/vlib/init.c:146
#10 0x2b687f479908 in vlib_main (vm=vm@entry=0x2b687f6cb260 
, input=input@entry=0x2b6884266fa0)
at 
/bfs-build/build-area.49/builds/LinuxNBngp_7.X_RH7/2018-11-16-0505/third-party/vpp/vpp_1801/build-data/../src/vlib/main.c:1772
#11 0x2b687f4b0b23 in thread0 (arg=47727814423136) at 
/bfs-build/build-area.49/builds/LinuxNBngp_7.X_RH7/2018-11-16-0505/third-party/vpp/vpp_1801/build-data/../src/vlib/unix/main.c:567
#12 0x2b68807e38b8 in clib_calljmp () at 
/bfs-build/build-area.49/builds/LinuxNBngp_7.X_RH7/2018-11-16-0505/third-party/vpp/vpp_1801/build-data/../src/vppinfra/longjmp.S:110
#13 0x7ffe03c4a0e0 in ?? ()
#14 0x2b687f4b187f in vlib_unix_main (argc=, argv=) at 
/bfs-build/build-area.49/builds/LinuxNBngp_7.X_RH7/2018-11-16-0505/third-party/vpp/vpp_1801/build-data/../src/vlib/unix/main.c:631
#15 0x6f2d326c0028 in ?? ()
#16 0x6c632d7475707475 in ?? ()
#17 0x4c20796669737361 in ?? ()
#18 0x697373616c432032 in ?? ()
#19 0x73706f7244207966 in ?? ()
#20 0x6425203a in ?? ()
#21 0x in ?? ()


VPP version: 18.01

After analysing back-trace, it is observed that in 
rte_mempool_populate_iova_tab iova address is NULL which is called by 
dpdk_pool_create passing pr->page_table addr as iova address.
pr : vlib_physmem_region_t *pr;
Before calling rte_mempool_populate_iova_tab, vlib_physmem_region_alloc is 
called which internally calls vm->os_physmem_region_alloc.

vm->os_physmem_region_alloc  is mapped to unix_physmem_region_alloc.
So in unix_physmem_region_alloc,
pr->page_table = clib_mem_vm_get_paddr (pr->mem, pr->log2_page_size, 
pr->n_pages);
Looks like clib_mem_vm_get_paddr is returning NULL to page table address.

Code for clib_mem_vm_get_paddr function
u64 *
clib_mem_vm_get_paddr (void *mem, int log2_page_size, int n_pages)
{
  int pagesize = sysconf (_SC_PAGESIZE);
  int fd;
  int i;
  u64 *r = 0;

  if ((fd = open ((char *) "/proc/self/pagemap", O_RDONLY)) == -1)
return 0;

  for (i = 0; i < n_pages; i++)
{
  u64 seek, pagemap = 0;
  uword vaddr = pointer_to_uword (mem) + (((u64) i) << log2_page_size);
  seek = ((u64) vaddr / pagesize) * sizeof (u64);
  if (lseek (fd, seek, SEEK_SET) != seek)
goto done;

  if (read (fd, , sizeof (pagemap)) != (sizeof (pagemap)))
goto done;

  if ((pagemap & (1ULL << 63)) == 0)
goto done;

  pagemap &= pow2_mask (55);
  vec_add1 (r, pagemap * pagesize);
}

done:
  close (fd);
  if (vec_len (r) != n_pages)
{
  vec_free (r);
  return 0;
}
  return r;
}

So why this could be returning NULL.  Any help would be appreciated.