[vpp-dev] [wg]: Assigning threads to wireguard peers

[Mahdi Varasteh]

Hello folks,

Looking at `wg_peer_assign_thread` function One can see the logic behind peer 
thread assigning which is: " Use the same thread that the packet has come from, 
unless its main thread. In main thread case, randomly choose a worker thread to 
handoff".

I understand assigning all peers uniformly to threads, can ( potentially) cause 
overall performance penalty. But in case of having lots of peers, all coming 
from the same interface, having more threads to handle them can become handy. 
So is there any other reason, other than performance impacts, behind limiting 
thread assigning to the above logic?

Best regards,  
Mahdi

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20375): https://lists.fd.io/g/vpp-dev/message/20375
Mute This Topic: https://lists.fd.io/mt/86570818/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[vpp-dev] Linking DPDK libs to plugins

[bjeremy32]

Greetings,

 

Let me preface this by saying that I really do not know much about the CMake
utility. But I am trying to see if there is a way to make the DPDK libs
accessible to other plugins (aside from the dpdk plugin) that are in their
own project/subdirectory similar. I am working with v20.05 currently
(although we are upgrading to 21.06 if that make a difference).

 

Initially it was suggested to me that I could just add a couple lines to my
CMakeLists to link the dpdk_plugin.so to my own plugin.. but I have not been
able to get this to work.. It never seems to recognize the path to the .so,
even if I give the absolute path

 

set(DPDK_PLUGIN_LINK_FLAGS "${DPDK_PLUGIN_LINK_FLAGS} -L  -ldpdk_plugin.so")

 

add_vpp_plugin(my_plugin

..

  LINK_FLAGS

  "${ DPDK_PLUGIN_LINK_FLAGS }"

 

Another approach suggested was to maybe use dlsym to dynamically load
symbols. Anyway, I was thinking that someone has to have had done this
before, or maybe have more of a clue as to how to do this then I currently
do.

 

 

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20374): https://lists.fd.io/g/vpp-dev/message/20374
Mute This Topic: https://lists.fd.io/mt/86565585/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] Does memif zero-copy work ?

[Damjan Marion via lists.fd.io]

> 
> On 24.10.2021., at 18:08, Mrityunjay Kumar  wrote:
> 
> 
> Well, almost VPP experts/users are familiar about dpdk. 

I don’t understand why somebody needs to be familiar with DPDK to use memif.
Actually we see more and more people looking to use VPP without DPDK so we have 
significant amount of native drivers which allows people to turn DPDK plugin 
and reduce weight it comes with. One of them is memif.

> 
> But dollor price question,  which one is stable one and less effort to marry 
> with VPP over shared memory, 

VPP memif implementation is reference implementation of protocol. DPDK  
implementation was just a port to enable people who have applications already 
built on top of dpdk framework to connect to VPP. AFAIK we never did serious 
optimizations to that code. I was not checking recently if somebody else did 
any improvements there…

Using DPDK PMD in VPP is also bad idea due to high cost of translation between 
VPP and DPDK data structures.  It is not only memif pmd, VPP with any other 
DPDK PMD is significantly slower than VPP with native driver. Also use of DPDK 
PMDs in VPP lack dynamic interface creation… Not to mention how nice is to get 
a rid of DPDK EAL…

> 
> I suggest, VPP user have both option open,  let them decide, which one is 
> better and convenient for them. 

I disagree as use of memif DPDK PMD in VPP brings zero value, and comes with 
lot of weight including significant performance penalty, less flexibility and 
high cost of mandatory use of EAL.

— 
Damjan
> 
> 
> 
> 
>> On Sun, 24 Oct, 2021, 4:28 pm Damjan Marion,  wrote:
>> 
>> And what is the benefit of doing that?
>> 
>> — 
>> Damjan
>> 
>> 
>> 
>>> On 24.10.2021., at 11:24, Mrityunjay Kumar  wrote:
>>> 
>>> Well, I can dump my opinion regarding this.  we can disable memif plugin 
>>> and  same feature can be achieved using dpdk EAL option.  For details 
>>> please refer bellow link.
>>> 
>>> https://doc.dpdk.org/guides/nics/memif.html
>>> 
>>>  
>>> 
>>> This required small patch by adding a new statrup.conf section under dpdk { 
>>> --vdev=net_memif0, net_memif1, … } , to handle this we need to translate 
>>> this in dpdk plugin to inject EAL in rte_eal_init.
>>> 
>>>  
>>> 
>>> 
 On Sun, 24 Oct, 2021, 5:16 am Damjan Marion,  wrote:
 What is your suggestion? Which part of the plugin is wrongly written?
 
 — 
 Damjan
 
>> On 24.10.2021., at 00:16, Mrityunjay Kumar  wrote:
>> 
> 
> Damjan, 
> 
> I think you are trying to explain one copy always occurs in memif 
> communication, 
> 
> 
> Currently VPP memif plugin is wrongly/misleadingly written and it also 
> misguiding to VPP users. 
> 
> When I look this code long back,  it also misleading me. 
> 
> 
> 
>> On Sat, 23 Oct, 2021, 11:52 pm Damjan Marion via lists.fd.io, 
>>  wrote:
>> 
>> Please note that “zero copy memif” doesn’t exist.
>> 
>> Long time ago I possibly wrongly/misleadingly added VPP feature with 
>> name “zero-copy slave”.
>> 
>> It is vpp internal feature which avoids 2nd memcopy by exposing VPP 
>> (slave only) buffers directly to master.
>> In such scenario still one memcpy exists….
>> 
>> 
>> — 
>> Damjan
>> 
>> 
>> 
>> > On 22.10.2021., at 13:19, Satya Murthy  
>> > wrote:
>> > 
>> > Thanks MJ for the quick reply.
>> > Will try this and check.
>> > 
>> > -- 
>> > Thanks & Regards,
>> > Murthy 
>> > 
>> > 
>> 
>> 
>> 
>> 
>> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20373): https://lists.fd.io/g/vpp-dev/message/20373
Mute This Topic: https://lists.fd.io/mt/86509719/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] Does memif zero-copy work ?

[Mrityunjay Kumar]

Well, almost VPP experts/users are familiar about dpdk.

But dollor price question,  which one is stable one and less effort to
marry with VPP over shared memory,


I suggest, VPP user have both option open,  let them decide, which one is
better and convenient for them.




On Sun, 24 Oct, 2021, 4:28 pm Damjan Marion,  wrote:

>
> And what is the benefit of doing that?
>
> —
> Damjan
>
>
>
> On 24.10.2021., at 11:24, Mrityunjay Kumar  wrote:
>
> Well, I can dump my opinion regarding this.  we can disable memif plugin
> and  same feature can be achieved using dpdk EAL option.  For details
> please refer bellow link.
>
> https://doc.dpdk.org/guides/nics/memif.html
>
>
>
> This required small patch by adding a new statrup.conf section under dpdk
> { --vdev=net_memif0, net_memif1, … } , to handle this we need to
> translate this in dpdk plugin to inject EAL in rte_eal_init.
>
>
>
> On Sun, 24 Oct, 2021, 5:16 am Damjan Marion,  wrote:
>
>> What is your suggestion? Which part of the plugin is wrongly written?
>>
>> —
>> Damjan
>>
>> On 24.10.2021., at 00:16, Mrityunjay Kumar  wrote:
>>
>> 
>> Damjan,
>>
>> I think you are trying to explain one copy always occurs in memif
>> communication,
>>
>>
>> Currently VPP memif plugin is wrongly/misleadingly written and it also
>> misguiding to VPP users.
>>
>> When I look this code long back,  it also misleading me.
>>
>>
>>
>> On Sat, 23 Oct, 2021, 11:52 pm Damjan Marion via lists.fd.io, > me@lists.fd.io> wrote:
>>
>>>
>>> Please note that “zero copy memif” doesn’t exist.
>>>
>>> Long time ago I possibly wrongly/misleadingly added VPP feature with
>>> name “zero-copy slave”.
>>>
>>> It is vpp internal feature which avoids 2nd memcopy by exposing VPP
>>> (slave only) buffers directly to master.
>>> In such scenario still one memcpy exists….
>>>
>>>
>>> —
>>> Damjan
>>>
>>>
>>>
>>> > On 22.10.2021., at 13:19, Satya Murthy 
>>> wrote:
>>> >
>>> > Thanks MJ for the quick reply.
>>> > Will try this and check.
>>> >
>>> > --
>>> > Thanks & Regards,
>>> > Murthy
>>> >
>>> >
>>>
>>>
>>> 
>>>
>>>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20372): https://lists.fd.io/g/vpp-dev/message/20372
Mute This Topic: https://lists.fd.io/mt/86509719/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] Does memif zero-copy work ?

[Damjan Marion via lists.fd.io]

And what is the benefit of doing that?

— 
Damjan



> On 24.10.2021., at 11:24, Mrityunjay Kumar  wrote:
> 
> Well, I can dump my opinion regarding this.  we can disable memif plugin and  
> same feature can be achieved using dpdk EAL option.  For details please refer 
> bellow link.
> 
> https://doc.dpdk.org/guides/nics/memif.html 
> 
>  
> 
> This required small patch by adding a new statrup.conf section under dpdk { 
> --vdev=net_memif0, net_memif1, … } , to handle this we need to translate this 
> in dpdk plugin to inject EAL in rte_eal_init.
> 
>  
> 
> 
> On Sun, 24 Oct, 2021, 5:16 am Damjan Marion,  > wrote:
> What is your suggestion? Which part of the plugin is wrongly written?
> 
> — 
> Damjan
> 
>> On 24.10.2021., at 00:16, Mrityunjay Kumar > > wrote:
>> 
>> 
>> Damjan, 
>> 
>> I think you are trying to explain one copy always occurs in memif 
>> communication, 
>> 
>> 
>> Currently VPP memif plugin is wrongly/misleadingly written and it also 
>> misguiding to VPP users. 
>> 
>> When I look this code long back,  it also misleading me. 
>> 
>> 
>> 
>> On Sat, 23 Oct, 2021, 11:52 pm Damjan Marion via lists.fd.io 
>> , > > wrote:
>> 
>> Please note that “zero copy memif” doesn’t exist.
>> 
>> Long time ago I possibly wrongly/misleadingly added VPP feature with name 
>> “zero-copy slave”.
>> 
>> It is vpp internal feature which avoids 2nd memcopy by exposing VPP (slave 
>> only) buffers directly to master.
>> In such scenario still one memcpy exists….
>> 
>> 
>> — 
>> Damjan
>> 
>> 
>> 
>> > On 22.10.2021., at 13:19, Satya Murthy > > > wrote:
>> > 
>> > Thanks MJ for the quick reply.
>> > Will try this and check.
>> > 
>> > -- 
>> > Thanks & Regards,
>> > Murthy 
>> > 
>> > 
>> 
>> 
>> 
>> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20371): https://lists.fd.io/g/vpp-dev/message/20371
Mute This Topic: https://lists.fd.io/mt/86509719/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] Does memif zero-copy work ?

[Mrityunjay Kumar]

Well, I can dump my opinion regarding this.  we can disable memif plugin
and  same feature can be achieved using dpdk EAL option.  For details
please refer bellow link.

https://doc.dpdk.org/guides/nics/memif.html



This required small patch by adding a new statrup.conf section under
dpdk { --vdev=net_memif0,
net_memif1, … } , to handle this we need to translate this in dpdk plugin
to inject EAL in rte_eal_init.



On Sun, 24 Oct, 2021, 5:16 am Damjan Marion,  wrote:

> What is your suggestion? Which part of the plugin is wrongly written?
>
> —
> Damjan
>
> On 24.10.2021., at 00:16, Mrityunjay Kumar  wrote:
>
> 
> Damjan,
>
> I think you are trying to explain one copy always occurs in memif
> communication,
>
>
> Currently VPP memif plugin is wrongly/misleadingly written and it also
> misguiding to VPP users.
>
> When I look this code long back,  it also misleading me.
>
>
>
> On Sat, 23 Oct, 2021, 11:52 pm Damjan Marion via lists.fd.io,  me@lists.fd.io> wrote:
>
>>
>> Please note that “zero copy memif” doesn’t exist.
>>
>> Long time ago I possibly wrongly/misleadingly added VPP feature with name
>> “zero-copy slave”.
>>
>> It is vpp internal feature which avoids 2nd memcopy by exposing VPP
>> (slave only) buffers directly to master.
>> In such scenario still one memcpy exists….
>>
>>
>> —
>> Damjan
>>
>>
>>
>> > On 22.10.2021., at 13:19, Satya Murthy 
>> wrote:
>> >
>> > Thanks MJ for the quick reply.
>> > Will try this and check.
>> >
>> > --
>> > Thanks & Regards,
>> > Murthy
>> >
>> >
>>
>>
>> 
>>
>>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#20370): https://lists.fd.io/g/vpp-dev/message/20370
Mute This Topic: https://lists.fd.io/mt/86509719/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-