date:20170707

Re: [vpp-dev] set mapping from node to thread

2017-07-07 Thread Rekha Rawat (rrawat)

 www w×××Sent from my Verizon, Samsung Galaxy smartphone

 Original message 
From: Florin Coras 
Date: 7/8/17 6:41 AM (GMT+05:30)
To: Yuliang Li 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] set mapping from node to thread

Hi Yuliang,

Are you running with dpdk or with tap/af_packet interfaces? As far as I 
remember multithreading for the last two might not work properly.

Florin

On Jul 7, 2017, at 5:55 PM, Yuliang aaa!a@@aaaa××aaa 
> wrote:

I printed 3 thread_index, and all 3 shows the same value:

1. vlib_frame_t's thread_index:
For each pending frame p:
vlib_pending_frame_t *p = nm->pending_frames + i;
I get the vlib_frame_t f:
vlib_frame_t *f = vlib_get_frame (vm, p->frame_index);
and I print f->thread_index

2. vlib_node_runtime_t's thread_indes:
For each pending frame p, I get its node runtime nr:
vlib_node_runtime_t *nr = vec_elt_at_index 
(nm->nodes_by_type[VLIB_NODE_TYPE_INTERNAL], p->node_runtime_index);
and I print nr->thread_index

3. vlib_main_t's thread_index:
I print vm->thread_index

On Fri, Jul 7, 2017 at 5:37 PM, Dave Barach (dbarach) 
> wrote:
What exactly were you printing? Vlib_pending_frame_t’s don’t have a 
thread_index field...:

/* A frame pending dispatch by main loop. */
typedef struct
{
  /* Node and runtime for this frame. */
  u32 node_runtime_index;

  /* Frame index (in the heap). */
  u32 frame_index;

  /* Start of next frames for this node. */
  u32 next_frame_index;

  /* Special value for next_frame_index when there is no next frame. */
#define VLIB_PENDING_FRAME_NO_NEXT_FRAME ((u32) ~0)
} vlib_pending_frame_t;

Thanks… Dave

From: Yuliang Li [mailto:yuliang...@yale.edu]
Sent: Friday, July 7, 2017 8:04 PM
To: Dave Barach (dbarach) >
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] set mapping from node to thread

Hi Dave,

Thanks for the detailed response.

However, from the experiment I did, I see the same packet being processed by 
two threads. That is why I asked this question. Maybe I made some mistakes, 
here is what I did:

- In vlib_main_or_worker_loop function, I print out all pending frames here, as 
well as the thread_index of them, and the node name.
- I start the vpp with 4 worker threads, and set up SNAT according to the 
progressive tutorial.
- I run iperf that go through the SNAT.

The printed information shows that, each TCP packet from the inside to the 
outside of the SNAT will go through the ethernet-input and snat-in2out. But the 
thread_index at the ethernet-input is 2, while the thread_index at snat-in2out 
is 1.

Is the above expected?

Thanks,

On Fri, Jul 7, 2017 at 12:22 PM, Dave Barach (dbarach) 
> wrote:
Dear Yuliang,

From a high level: vpp creates N identical graph replicas in a multi-core 
configuration. When practicable, we use hardware RSS hashing to ensure that all 
packets belonging to a specific flow are processed [in order!] by the same 
thread / graph replica. In effect, embarrassing parallelism.

It’s easy enough to hand off packets between threads - see the “handoff-node” - 
but we avoid that whenever possible.

Although one could - and I have - divided graph nodes across threads to create 
pipelines, that scheme needs significant dynamic tuning to handle a traffic 
pattern change. It’s hard to map nodes onto cores so that each thread in a 
pipeline uses approximately the same number of clocks/pkt; critical, since 
pipelines run at the speed of the slowest stage.

It’s possible to hand off a full frame of packets for less than two clocks/pkt. 
Unfortunately, that’s the least significant issue. Handing off a packet from 
one core/thread to another guarantees a bunch of memory/cache subsystem 
pressure as the system moves packet data and metadata from A to B.

HTH... Dave

From: vpp-dev-boun...@lists.fd.io 
[mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Yuliang Li
Sent: Friday, July 7, 2017 1:14 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] set mapping from node to thread

Hi,

Is there a way to set which node should run on which thread? And is there a 
command that shows the mapping from nodes to threads?

Thanks,
--
Yuliang Li
PhD student
Department of Computer Science
Yale University

--
Yuliang Li
PhD student
Department of Computer Science
Yale University

--
Yuliang Li
PhD student
Department of Computer Science
Yale University
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

___
vpp-dev mailing list

Re: [vpp-dev] set mapping from node to thread

2017-07-07 Thread Yuliang Li

I am using af_packet... I will try dpdk.

On Fri, Jul 7, 2017 at 6:11 PM, Florin Coras  wrote:

> Hi Yuliang,
>
> Are you running with dpdk or with tap/af_packet interfaces? As far as I
> remember multithreading for the last two might not work properly.
>
> Florin
>
> On Jul 7, 2017, at 5:55 PM, Yuliang Li  wrote:
>
> I printed 3 thread_index, and all 3 shows the same value:
>
> 1. vlib_frame_t's thread_index:
> For each pending frame p:
>
> vlib_pending_frame_t *p = nm->pending_frames + i;
>
> I get the vlib_frame_t f:
>
> vlib_frame_t *f = vlib_get_frame (vm, p->frame_index);
>
> and I print f->thread_index
>
> 2. vlib_node_runtime_t's thread_indes:
> For each pending frame p, I get its node runtime nr:
>
> vlib_node_runtime_t *nr = vec_elt_at_index 
> (nm->nodes_by_type[VLIB_NODE_TYPE_INTERNAL],
> p->node_runtime_index);
>
> and I print nr->thread_index
>
> 3. vlib_main_t's thread_index:
> I print vm->thread_index
>
>
> On Fri, Jul 7, 2017 at 5:37 PM, Dave Barach (dbarach) 
> wrote:
>
>> What exactly were you printing? Vlib_pending_frame_t’s don’t have a
>> thread_index field...:
>>
>>
>>
>>
>>
>> /* A frame pending dispatch by main loop. */
>>
>> typedef struct
>>
>> {
>>
>>   /* Node and runtime for this frame. */
>>
>>   u32 node_runtime_index;
>>
>>
>>
>>   /* Frame index (in the heap). */
>>
>>   u32 frame_index;
>>
>>
>>
>>   /* Start of next frames for this node. */
>>
>>   u32 next_frame_index;
>>
>>
>>
>>   /* Special value for next_frame_index when there is no next frame. */
>>
>> #define VLIB_PENDING_FRAME_NO_NEXT_FRAME ((u32) ~0)
>>
>> } vlib_pending_frame_t;
>>
>>
>>
>> Thanks… Dave
>>
>>
>>
>> *From:* Yuliang Li [mailto:yuliang...@yale.edu]
>> *Sent:* Friday, July 7, 2017 8:04 PM
>> *To:* Dave Barach (dbarach) 
>> *Cc:* vpp-dev@lists.fd.io
>> *Subject:* Re: [vpp-dev] set mapping from node to thread
>>
>>
>>
>> Hi Dave,
>>
>>
>>
>> Thanks for the detailed response.
>>
>>
>>
>> However, from the experiment I did, I see the same packet being processed
>> by two threads. That is why I asked this question. Maybe I made some
>> mistakes, here is what I did:
>>
>>
>>
>> - In *vlib_main_or_worker_loop* function, I print out all pending frames
>> here, as well as the thread_index of them, and the node name.
>>
>> - I start the vpp with 4 worker threads, and set up SNAT according to the
>>  progressive tutorial
>> .
>>
>> - I run iperf that go through the SNAT.
>>
>>
>>
>> The printed information shows that, each TCP packet from the inside to
>> the outside of the SNAT will go through the ethernet-input and snat-in2out.
>> But the thread_index at the ethernet-input is 2, while the thread_index at
>> snat-in2out is 1.
>>
>>
>>
>> Is the above expected?
>>
>>
>>
>> Thanks,
>>
>>
>>
>> On Fri, Jul 7, 2017 at 12:22 PM, Dave Barach (dbarach) 
>> wrote:
>>
>> Dear Yuliang,
>>
>>
>>
>> From a high level: vpp creates N identical graph replicas in a multi-core
>> configuration. When practicable, we use hardware RSS hashing to ensure that
>> all packets belonging to a specific flow are processed [in order!] by the
>> same thread / graph replica. In effect, embarrassing parallelism.
>>
>>
>>
>> It’s easy enough to hand off packets between threads - see the
>> “handoff-node” - but we avoid that whenever possible.
>>
>>
>>
>> Although one could - and I have - divided graph nodes across threads to
>> create pipelines, that scheme needs significant dynamic tuning to handle a
>> traffic pattern change. It’s hard to map nodes onto cores so that each
>> thread in a pipeline uses approximately the same number of clocks/pkt;
>> critical, since pipelines run at the speed of the slowest stage.
>>
>>
>>
>> It’s possible to hand off a full frame of packets for less than two
>> clocks/pkt. Unfortunately, that’s the least significant issue. Handing off
>> a packet from one core/thread to another guarantees a bunch of memory/cache
>> subsystem pressure as the system moves packet data and metadata from A to
>> B.
>>
>>
>>
>> HTH... Dave
>>
>>
>>
>> *From:* vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] *On
>> Behalf Of *Yuliang Li
>> *Sent:* Friday, July 7, 2017 1:14 PM
>> *To:* vpp-dev@lists.fd.io
>> *Subject:* [vpp-dev] set mapping from node to thread
>>
>>
>>
>> Hi,
>>
>>
>>
>> Is there a way to set which node should run on which thread? And is there
>> a command that shows the mapping from nodes to threads?
>>
>>
>>
>> Thanks,
>>
>> --
>>
>> Yuliang Li
>>
>> PhD student
>>
>> Department of Computer Science
>>
>> Yale University
>>
>>
>>
>>
>>
>> --
>>
>> Yuliang Li
>>
>> PhD student
>>
>> Department of Computer Science
>>
>> Yale University
>>
>
>
>
> --
> Yuliang Li
> PhD student
> Department of Computer Science
> Yale University
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
>

Re: [vpp-dev] set mapping from node to thread

2017-07-07 Thread Florin Coras

Hi Yuliang, 

Are you running with dpdk or with tap/af_packet interfaces? As far as I 
remember multithreading for the last two might not work properly. 

Florin

> On Jul 7, 2017, at 5:55 PM, Yuliang Li  wrote:
> 
> I printed 3 thread_index, and all 3 shows the same value: 
> 
> 1. vlib_frame_t's thread_index:
> For each pending frame p: 
> vlib_pending_frame_t *p = nm->pending_frames + i;
> I get the vlib_frame_t f: 
> vlib_frame_t *f = vlib_get_frame (vm, p->frame_index);
> and I print f->thread_index
> 
> 2. vlib_node_runtime_t's thread_indes:
> For each pending frame p, I get its node runtime nr:
> vlib_node_runtime_t *nr = vec_elt_at_index 
> (nm->nodes_by_type[VLIB_NODE_TYPE_INTERNAL], p->node_runtime_index);
> and I print nr->thread_index
> 
> 3. vlib_main_t's thread_index:
> I print vm->thread_index
> 
> 
> On Fri, Jul 7, 2017 at 5:37 PM, Dave Barach (dbarach)  > wrote:
> What exactly were you printing? Vlib_pending_frame_t’s don’t have a 
> thread_index field...: <>
>  
> 
>  
> 
> /* A frame pending dispatch by main loop. */
> 
> typedef struct
> 
> {
> 
>   /* Node and runtime for this frame. */
> 
>   u32 node_runtime_index;
> 
>  
> 
>   /* Frame index (in the heap). */
> 
>   u32 frame_index;
> 
>  
> 
>   /* Start of next frames for this node. */
> 
>   u32 next_frame_index;
> 
>  
> 
>   /* Special value for next_frame_index when there is no next frame. */
> 
> #define VLIB_PENDING_FRAME_NO_NEXT_FRAME ((u32) ~0)
> 
> } vlib_pending_frame_t;
> 
>  
> 
> Thanks… Dave
> 
>  
> 
> From: Yuliang Li [mailto:yuliang...@yale.edu ] 
> Sent: Friday, July 7, 2017 8:04 PM
> To: Dave Barach (dbarach) >
> Cc: vpp-dev@lists.fd.io 
> Subject: Re: [vpp-dev] set mapping from node to thread
> 
>  
> 
> Hi Dave,
> 
>  
> 
> Thanks for the detailed response. 
> 
>  
> 
> However, from the experiment I did, I see the same packet being processed by 
> two threads. That is why I asked this question. Maybe I made some mistakes, 
> here is what I did:
> 
>  
> 
> - In vlib_main_or_worker_loop function, I print out all pending frames here, 
> as well as the thread_index of them, and the node name.
> 
> - I start the vpp with 4 worker threads, and set up SNAT according to the 
> progressive tutorial .
> 
> - I run iperf that go through the SNAT.
> 
>  
> 
> The printed information shows that, each TCP packet from the inside to the 
> outside of the SNAT will go through the ethernet-input and snat-in2out. But 
> the thread_index at the ethernet-input is 2, while the thread_index at 
> snat-in2out is 1.
> 
>  
> 
> Is the above expected?
> 
>  
> 
> Thanks,
> 
>  
> 
> On Fri, Jul 7, 2017 at 12:22 PM, Dave Barach (dbarach)  > wrote:
> 
> Dear Yuliang, <>
>  
> 
> From a high level: vpp creates N identical graph replicas in a multi-core 
> configuration. When practicable, we use hardware RSS hashing to ensure that 
> all packets belonging to a specific flow are processed [in order!] by the 
> same thread / graph replica. In effect, embarrassing parallelism.
> 
>  
> 
> It’s easy enough to hand off packets between threads - see the “handoff-node” 
> - but we avoid that whenever possible.
> 
>  
> 
> Although one could - and I have - divided graph nodes across threads to 
> create pipelines, that scheme needs significant dynamic tuning to handle a 
> traffic pattern change. It’s hard to map nodes onto cores so that each thread 
> in a pipeline uses approximately the same number of clocks/pkt; critical, 
> since pipelines run at the speed of the slowest stage.
> 
>  
> 
> It’s possible to hand off a full frame of packets for less than two 
> clocks/pkt. Unfortunately, that’s the least significant issue. Handing off a 
> packet from one core/thread to another guarantees a bunch of memory/cache 
> subsystem pressure as the system moves packet data and metadata from A to B.  
> 
>  
> 
> HTH... Dave
> 
>  
> 
> From: vpp-dev-boun...@lists.fd.io  
> [mailto:vpp-dev-boun...@lists.fd.io ] On 
> Behalf Of Yuliang Li
> Sent: Friday, July 7, 2017 1:14 PM
> To: vpp-dev@lists.fd.io 
> Subject: [vpp-dev] set mapping from node to thread
> 
>  
> 
> Hi,
> 
>  
> 
> Is there a way to set which node should run on which thread? And is there a 
> command that shows the mapping from nodes to threads?
> 
>  
> 
> Thanks,
> 
> --
> 
> Yuliang Li
> 
> PhD student
> 
> Department of Computer Science
> 
> Yale University
> 
> 
> 
> 
>  
> 
> -- 
> 
> Yuliang Li
> 
> PhD student
> 
> Department of Computer Science
> 
> Yale University
> 
> 
> 
> 
> -- 
> Yuliang Li
> PhD student
> Department of Computer Science
> Yale University
> ___
>

Re: [vpp-dev] set mapping from node to thread

2017-07-07 Thread Yuliang Li

I printed 3 thread_index, and all 3 shows the same value:

1. vlib_frame_t's thread_index:
For each pending frame p:

vlib_pending_frame_t *p = nm->pending_frames + i;

I get the vlib_frame_t f:

vlib_frame_t *f = vlib_get_frame (vm, p->frame_index);

and I print f->thread_index

2. vlib_node_runtime_t's thread_indes:
For each pending frame p, I get its node runtime nr:

vlib_node_runtime_t *nr = vec_elt_at_index
(nm->nodes_by_type[VLIB_NODE_TYPE_INTERNAL], p->node_runtime_index);

and I print nr->thread_index

3. vlib_main_t's thread_index:
I print vm->thread_index


On Fri, Jul 7, 2017 at 5:37 PM, Dave Barach (dbarach) 
wrote:

> What exactly were you printing? Vlib_pending_frame_t’s don’t have a
> thread_index field...:
>
>
>
>
>
> /* A frame pending dispatch by main loop. */
>
> typedef struct
>
> {
>
>   /* Node and runtime for this frame. */
>
>   u32 node_runtime_index;
>
>
>
>   /* Frame index (in the heap). */
>
>   u32 frame_index;
>
>
>
>   /* Start of next frames for this node. */
>
>   u32 next_frame_index;
>
>
>
>   /* Special value for next_frame_index when there is no next frame. */
>
> #define VLIB_PENDING_FRAME_NO_NEXT_FRAME ((u32) ~0)
>
> } vlib_pending_frame_t;
>
>
>
> Thanks… Dave
>
>
>
> *From:* Yuliang Li [mailto:yuliang...@yale.edu]
> *Sent:* Friday, July 7, 2017 8:04 PM
> *To:* Dave Barach (dbarach) 
> *Cc:* vpp-dev@lists.fd.io
> *Subject:* Re: [vpp-dev] set mapping from node to thread
>
>
>
> Hi Dave,
>
>
>
> Thanks for the detailed response.
>
>
>
> However, from the experiment I did, I see the same packet being processed
> by two threads. That is why I asked this question. Maybe I made some
> mistakes, here is what I did:
>
>
>
> - In *vlib_main_or_worker_loop* function, I print out all pending frames
> here, as well as the thread_index of them, and the node name.
>
> - I start the vpp with 4 worker threads, and set up SNAT according to the 
> progressive
> tutorial .
>
> - I run iperf that go through the SNAT.
>
>
>
> The printed information shows that, each TCP packet from the inside to the
> outside of the SNAT will go through the ethernet-input and snat-in2out. But
> the thread_index at the ethernet-input is 2, while the thread_index at
> snat-in2out is 1.
>
>
>
> Is the above expected?
>
>
>
> Thanks,
>
>
>
> On Fri, Jul 7, 2017 at 12:22 PM, Dave Barach (dbarach) 
> wrote:
>
> Dear Yuliang,
>
>
>
> From a high level: vpp creates N identical graph replicas in a multi-core
> configuration. When practicable, we use hardware RSS hashing to ensure that
> all packets belonging to a specific flow are processed [in order!] by the
> same thread / graph replica. In effect, embarrassing parallelism.
>
>
>
> It’s easy enough to hand off packets between threads - see the
> “handoff-node” - but we avoid that whenever possible.
>
>
>
> Although one could - and I have - divided graph nodes across threads to
> create pipelines, that scheme needs significant dynamic tuning to handle a
> traffic pattern change. It’s hard to map nodes onto cores so that each
> thread in a pipeline uses approximately the same number of clocks/pkt;
> critical, since pipelines run at the speed of the slowest stage.
>
>
>
> It’s possible to hand off a full frame of packets for less than two
> clocks/pkt. Unfortunately, that’s the least significant issue. Handing off
> a packet from one core/thread to another guarantees a bunch of memory/cache
> subsystem pressure as the system moves packet data and metadata from A to
> B.
>
>
>
> HTH... Dave
>
>
>
> *From:* vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] *On
> Behalf Of *Yuliang Li
> *Sent:* Friday, July 7, 2017 1:14 PM
> *To:* vpp-dev@lists.fd.io
> *Subject:* [vpp-dev] set mapping from node to thread
>
>
>
> Hi,
>
>
>
> Is there a way to set which node should run on which thread? And is there
> a command that shows the mapping from nodes to threads?
>
>
>
> Thanks,
>
> --
>
> Yuliang Li
>
> PhD student
>
> Department of Computer Science
>
> Yale University
>
>
>
>
>
> --
>
> Yuliang Li
>
> PhD student
>
> Department of Computer Science
>
> Yale University
>



-- 
Yuliang Li
PhD student
Department of Computer Science
Yale University
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] set mapping from node to thread

2017-07-07 Thread Dave Barach (dbarach)

What exactly were you printing? Vlib_pending_frame_t’s don’t have a 
thread_index field...:


/* A frame pending dispatch by main loop. */
typedef struct
{
  /* Node and runtime for this frame. */
  u32 node_runtime_index;

  /* Frame index (in the heap). */
  u32 frame_index;

  /* Start of next frames for this node. */
  u32 next_frame_index;

  /* Special value for next_frame_index when there is no next frame. */
#define VLIB_PENDING_FRAME_NO_NEXT_FRAME ((u32) ~0)
} vlib_pending_frame_t;

Thanks… Dave

From: Yuliang Li [mailto:yuliang...@yale.edu]
Sent: Friday, July 7, 2017 8:04 PM
To: Dave Barach (dbarach) 
Cc: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] set mapping from node to thread

Hi Dave,

Thanks for the detailed response.

However, from the experiment I did, I see the same packet being processed by 
two threads. That is why I asked this question. Maybe I made some mistakes, 
here is what I did:

- In vlib_main_or_worker_loop function, I print out all pending frames here, as 
well as the thread_index of them, and the node name.
- I start the vpp with 4 worker threads, and set up SNAT according to the 
progressive tutorial.
- I run iperf that go through the SNAT.

The printed information shows that, each TCP packet from the inside to the 
outside of the SNAT will go through the ethernet-input and snat-in2out. But the 
thread_index at the ethernet-input is 2, while the thread_index at snat-in2out 
is 1.

Is the above expected?

Thanks,

On Fri, Jul 7, 2017 at 12:22 PM, Dave Barach (dbarach) 
> wrote:
Dear Yuliang,

From a high level: vpp creates N identical graph replicas in a multi-core 
configuration. When practicable, we use hardware RSS hashing to ensure that all 
packets belonging to a specific flow are processed [in order!] by the same 
thread / graph replica. In effect, embarrassing parallelism.

It’s easy enough to hand off packets between threads - see the “handoff-node” - 
but we avoid that whenever possible.

Although one could - and I have - divided graph nodes across threads to create 
pipelines, that scheme needs significant dynamic tuning to handle a traffic 
pattern change. It’s hard to map nodes onto cores so that each thread in a 
pipeline uses approximately the same number of clocks/pkt; critical, since 
pipelines run at the speed of the slowest stage.

It’s possible to hand off a full frame of packets for less than two clocks/pkt. 
Unfortunately, that’s the least significant issue. Handing off a packet from 
one core/thread to another guarantees a bunch of memory/cache subsystem 
pressure as the system moves packet data and metadata from A to B.

HTH... Dave

From: vpp-dev-boun...@lists.fd.io 
[mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Yuliang Li
Sent: Friday, July 7, 2017 1:14 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] set mapping from node to thread

Hi,

Is there a way to set which node should run on which thread? And is there a 
command that shows the mapping from nodes to threads?

Thanks,
--
Yuliang Li
PhD student
Department of Computer Science
Yale University



--
Yuliang Li
PhD student
Department of Computer Science
Yale University
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] ACL commands

2017-07-07 Thread Yuliang Li

Hi,

Does anyone knows how to configure ACL in vpp? Is there any document?

Thanks,
-- 
Yuliang Li
PhD student
Department of Computer Science
Yale University
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] set mapping from node to thread

2017-07-07 Thread Dave Barach (dbarach)

Dear Yuliang,

From a high level: vpp creates N identical graph replicas in a multi-core 
configuration. When practicable, we use hardware RSS hashing to ensure that all 
packets belonging to a specific flow are processed [in order!] by the same 
thread / graph replica. In effect, embarrassing parallelism.

It’s easy enough to hand off packets between threads - see the “handoff-node” - 
but we avoid that whenever possible.

Although one could - and I have - divided graph nodes across threads to create 
pipelines, that scheme needs significant dynamic tuning to handle a traffic 
pattern change. It’s hard to map nodes onto cores so that each thread in a 
pipeline uses approximately the same number of clocks/pkt; critical, since 
pipelines run at the speed of the slowest stage.

It’s possible to hand off a full frame of packets for less than two clocks/pkt. 
Unfortunately, that’s the least significant issue. Handing off a packet from 
one core/thread to another guarantees a bunch of memory/cache subsystem 
pressure as the system moves packet data and metadata from A to B.

HTH... Dave

From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Yuliang Li
Sent: Friday, July 7, 2017 1:14 PM
To: vpp-dev@lists.fd.io
Subject: [vpp-dev] set mapping from node to thread

Hi,

Is there a way to set which node should run on which thread? And is there a 
command that shows the mapping from nodes to threads?

Thanks,
--
Yuliang Li
PhD student
Department of Computer Science
Yale University
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] set mapping from node to thread

2017-07-07 Thread Yuliang Li

Hi,

Is there a way to set which node should run on which thread? And is there a
command that shows the mapping from nodes to threads?

Thanks,
-- 
Yuliang Li
PhD student
Department of Computer Science
Yale University
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] 17.07 CIST Failures : FW: Change in vpp[stable/1704]: DHCP complete event includes the subnet mask

2017-07-07 Thread Dave Wallace

Maciek,

There have now been 4 attempts to verify my patch to stable/1704 all of 
which failed for different reasons (none of them related to my patch).  
Therefore I believe that we should move forward with your patch to 
resolve this issue in a timely fashion.

I have Code Review +1 your patch.

Thanks,
-daw-

On 07/06/2017 12:43 PM, Maciek Konstantynowicz (mkonstan) wrote:

I’m easy either way, community decides :)

-Maciek

On 6 Jul 2017, at 17:32, Maciek Konstantynowicz (mkonstan) 
> wrote:

Our emails crossed mid-air, so resending here.

Your patchwork https://gerrit.fd.io/r/#/c/7457/
Would need to applied to all stable VPP branches to make it work.

Can’t we do it by keeping the symlink in place, and my patch ?

-Maciek

On 6 Jul 2017, at 17:39, Dave Wallace > wrote:

Maciek,

My patch replicates the movement of the directory and adds the link 
in build-root/vagrant for backwards compatibility in the stable 
branches, so that we can remove the link in build-root/vagrant in master.

I'd prefer that we clean this up now and make build-root/vagrant go 
away in 17.10, but I'm willing to leave it in place if that is what 
the community desires.

Thanks,
-daw-

On 07/06/2017 12:25 PM, Maciek Konstantynowicz (mkonstan) wrote:

https://gerrit.fd.io/r/#/c/7459/

This should make it compatible for all branches IMV, as there is 
symbolic link in the right place, so no need to change:

build-root $ ls -la | grep vagrant
lrwxr-xr-x   1 maciek  staff 17  6 Jul 16:48 vagrant -> 
../extras/vagrant

Whoever move the directory back on 20-Apr thought about the cases 
like this :)

-Maciek

On 6 Jul 2017, at 17:16, Maciek Konstantynowicz (mkonstan) 
> wrote:

Dave, Looks like we’ve been working on this in parallel.
This is the fix, yes:

diff --git a/jjb/vpp/include-raw-vpp-build.sh 
b/jjb/vpp/include-raw-vpp-build.sh

index 5e603d2..582971c 100644
--- a/jjb/vpp/include-raw-vpp-build.sh
+++ b/jjb/vpp/include-raw-vpp-build.sh
@@ -32,16 +32,16 @@ echo "CC=${CC}"
 echo "IS_CSIT_VPP_JOB=${IS_CSIT_VPP_JOB}"
 # If and only if we are doing verify *after* make verify was made 
to work
 # and we are not a CSIT job just building packages, then use make 
verify,

-# else use the old extras/vagrant/build.sh
+# else use the old build-root/vagrant/build.sh
 if (git log --oneline | grep 37682e1 > /dev/null 2>&1) && \
 [ "x${IS_CSIT_VPP_JOB}" != "xTrue" ]
 then
 echo "Building using \"make verify\""
 [ "x${DRYRUN}" == "xTrue" ] || make UNATTENDED=yes verify
 else
-echo "Building using \"make extras/vagrant/build.sh\""
+echo "Building using \"make build-root/vagrant/build.sh\""
 [ "x${DRYRUN}" == "xTrue" ] || make UNATTENDED=yes 
dpdk-install-dev

-[ "x${DRYRUN}" == "xTrue" ] || extras/vagrant/build.sh
+[ "x${DRYRUN}" == "xTrue" ] || build-root/vagrant/build.sh
 fi

 if [ "x${VPP_REPO}" == "x1" ]; then

-Maciek

On 6 Jul 2017, at 16:17, Dave Wallace > wrote:

This is a side effect of a change made to ci-management 
(https://gerrit.fd.io/r/#/c/7173/).

I will fix this issue for the stable vpp branches.

Thanks,
-daw-

On 7/6/17 8:22 AM, Jan Gelety -X (jgelety - PANTHEON TECHNOLOGIES 
at Cisco) wrote:

Hello Neale,

If I am correct, it is necessary to move/copy vagrant directory from 
build-root/vagrant/ to extras/vagrant/ in stable/1704 branch.

Probably it should be done for all stable vpp branches.

Regards,
Jan

-Original Message-
From:vpp-dev-boun...@lists.fd.io  [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Neale Ranns (nranns)
Sent: Thursday, July 06, 2017 12:57
To:csit-...@lists.fd.io
Cc: vpp-dev
Subject: [vpp-dev] 17.07 CIST Failures : FW: Change in vpp[stable/1704]: DHCP 
complete event includes the subnet mask

Hi all,

The CSIT jobs on 17.07 have a consistent failure as of some time last night – 
error below.
Could I please ask for an investigation as a matter of some urgency.

Thanks,
Neale

08:42:24 make[1]: Entering directory '/w/workspace/vpp-csit-verify-virl-1704/dpdk'

08:42:24 Makefile:170: warning: overriding recipe for target 
'/w/workspace/vpp-csit-verify-virl-1704/dpdk/'
08:42:24 Makefile:164: warning: ignoring old recipe for target 
'/w/workspace/vpp-csit-verify-virl-1704/dpdk/'
08:42:25 ==
08:42:25  Up-to-date DPDK package already installed
08:42:25 ==
08:42:25 make[1]: Leaving directory 
'/w/workspace/vpp-csit-verify-virl-1704/dpdk'
08:42:25 + '[' x == xTrue ']'
08:42:25 + extras/vagrant/build.sh
08:42:25 /tmp/hudson5219485721951253061.sh: line 89: extras/vagrant/build.sh: 
No such file or directory

-Original Message-
From: "fd.io   JJB (Code Review)"

Re: [vpp-dev] set mapping from node to thread

Re: [vpp-dev] set mapping from node to thread

Re: [vpp-dev] set mapping from node to thread

Re: [vpp-dev] set mapping from node to thread

Re: [vpp-dev] set mapping from node to thread

[vpp-dev] ACL commands

Re: [vpp-dev] set mapping from node to thread

[vpp-dev] set mapping from node to thread

Re: [vpp-dev] 17.07 CIST Failures : FW: Change in vpp[stable/1704]: DHCP complete event includes the subnet mask

9 matches

Site Navigation

Mail list logo

Footer information