Re: [vpp-dev] [vpp] does vpp support interface hotplugin?

[Christophe FONTAINE]

Hi Yu,

Could you give me an example of the requirement of the physical hotplug for NFV 
?
FYI, vhost-user is already implemented: using VPP as a vswitch already works, 
so, hotplug of virtual interfaces already works.

The way I see this is:

-  SRIOV/PCI pass thru: vpp is not in the loop, and the physical 
interfaces are reserved, and connected to the VMs

-  VPP as a vswitch: you connect all your physical interfaces at 
startup, and your vms are connected to vpp thru vhost-user socket.

Christophe

From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of yu scott
Sent: jeudi 24 novembre 2016 08:52
To: vpp-dev@lists.fd.io
Subject: Re: [vpp-dev] [vpp] does vpp support interface hotplugin?

Hi Marion,

Does next release version  support hotplugins?
BTW, hotplugins is very importance for VPP used for NFV.

2016-11-24 4:13 GMT+08:00 Damjan Marion 
mailto:dmarion.li...@gmail.com>>:

> On 17 Nov 2016, at 03:07, Chillance Zen 
> mailto:chillance...@gmail.com>> wrote:
>
>
> Hi, dear all.
> as far as I know , vpp is derived from cisco 's mature commercial
> product,since accelerated with DPDK,it's very suitable for VNF appliance
> ,and also this is what we are gonna do.one thing which confuses me is how
> vpp supports plugable interface to make vpp more flexible since we do not
> restart vpp when a interface joins vpp.what's more ,DPDK does support port
> hotplugin with both pci dev and vdev.

We currently do not support hotplug of physical devices. It is not impossible
to add support but it will require some work...

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev


This message and any attachments (the "message") are confidential, intended 
solely for the addressees. If you are not the intended recipient, please notify 
the sender immediately by e-mail and delete this message from your system. In 
this case, you are not authorized to use, copy this message and/or disclose the 
content to any other person. E-mails are susceptible to alteration. Neither 
Qosmos nor any of its subsidiaries or affiliates shall be liable for the 
message if altered, changed or falsified.

Ce message et toutes ses pièces jointes (ci-après le "message")sont 
confidentiels et établis à l'intention exclusive de ses destinataires. Si vous 
avez reçu ce message par erreur, merci d’en informer immédiatement son émetteur 
par courrier électronique et d’effacer ce message de votre système. Dans cette 
hypothèse, vous n’êtes pas autorisé à utiliser, copier ce message et/ou en 
divulguer le contenu à un tiers. Tout message électronique est susceptible 
d'altération. Qosmos et ses filiales déclinent toute responsabilité au titre de 
ce message s'il a été altéré, déformé ou falsifié.
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] omg,vlan sub-interface seems not working

[Chillance Zen]

Hi,Damjan:

here is the trace output,it iterates that vpp can not find the ip address
which is to be resolved,but I've already configured it on the vlan-sub
interface already.

  130.140.25.1/24
DBGvpp# trace add dpdk-input 5
DBGvpp# show trace
--- Start of thread 0 vpp_main ---
Packet 1

00:01:53:640161: dpdk-input
  af_packet0 rx queue 0
  buffer 0x400392f: current data 0, length 42, free-list 0, totlen-nifb 0,
trace 0x0
  PKT MBUF: port 0, nb_segs 1, pkt_len 42
buf_len 2176, data_len 42, ol_flags 0x0, data_off 128, phys_addr
0x3d6e0ac0
packet_type 0x0
  ARP: f6:09:36:23:17:70 -> ff:ff:ff:ff:ff:ff
  request, type ethernet/IP4, address size 6/4
  f6:09:36:23:17:70/130.140.25.2 -> 00:00:00:00:00:00/130.140.25.1
00:01:53:640183: ethernet-input
  ARP: f6:09:36:23:17:70 -> ff:ff:ff:ff:ff:ff
00:01:53:640210: arp-input
  request, type ethernet/IP4, address size 6/4
  f6:09:36:23:17:70/130.140.25.2 -> 00:00:00:00:00:00/130.140.25.1
00:01:53:640214: error-drop
  arp-input: IP4 destination address not local to subnet

Packet 2

00:01:54:644159: dpdk-input
  af_packet0 rx queue 0
  buffer 0x400392f: current data 0, length 42, free-list 0, totlen-nifb 0,
trace 0x1
  PKT MBUF: port 0, nb_segs 1, pkt_len 42
buf_len 2176, data_len 42, ol_flags 0x0, data_off 128, phys_addr
0x3d6e0ac0
packet_type 0x0
  ARP: f6:09:36:23:17:70 -> ff:ff:ff:ff:ff:ff
  request, type ethernet/IP4, address size 6/4
  f6:09:36:23:17:70/130.140.25.2 -> 00:00:00:00:00:00/130.140.25.1
00:01:54:644176: ethernet-input
  ARP: f6:09:36:23:17:70 -> ff:ff:ff:ff:ff:ff
00:01:54:644199: arp-input
  request, type ethernet/IP4, address size 6/4
  f6:09:36:23:17:70/130.140.25.2 -> 00:00:00:00:00:00/130.140.25.1
00:01:54:644202: error-drop
  arp-input: IP4 destination address not local to subnet

Packet 3

00:01:56:630149: dpdk-input
  af_packet0 rx queue 0
  buffer 0x400392f: current data 0, length 42, free-list 0, totlen-nifb 0,
trace 0x2
  PKT MBUF: port 0, nb_segs 1, pkt_len 42
buf_len 2176, data_len 42, ol_flags 0x0, data_off 128, phys_addr
0x3d6e0ac0
packet_type 0x0
  ARP: f6:09:36:23:17:70 -> ff:ff:ff:ff:ff:ff
  request, type ethernet/IP4, address size 6/4
  f6:09:36:23:17:70/130.140.25.2 -> 00:00:00:00:00:00/130.140.25.1
00:01:56:642171: ethernet-input
  ARP: f6:09:36:23:17:70 -> ff:ff:ff:ff:ff:ff
00:01:56:642192: arp-input
  request, type ethernet/IP4, address size 6/4
  f6:09:36:23:17:70/130.140.25.2 -> 00:00:00:00:00:00/130.140.25.1
00:01:56:642197: error-drop
  arp-input: IP4 destination address not local to subnet

DBGvpp# show trace
--- Start of thread 0 vpp_main ---
Packet 1

00:01:53:640161: dpdk-input
  af_packet0 rx queue 0
  buffer 0x400392f: current data 0, length 42, free-list 0, totlen-nifb 0,
trace 0x0
  PKT MBUF: port 0, nb_segs 1, pkt_len 42
buf_len 2176, data_len 42, ol_flags 0x0, data_off 128, phys_addr
0x3d6e0ac0
packet_type 0x0
  ARP: f6:09:36:23:17:70 -> ff:ff:ff:ff:ff:ff
  request, type ethernet/IP4, address size 6/4
  f6:09:36:23:17:70/130.140.25.2 -> 00:00:00:00:00:00/130.140.25.1
00:01:53:640183: ethernet-input
  ARP: f6:09:36:23:17:70 -> ff:ff:ff:ff:ff:ff
00:01:53:640210: arp-input
  request, type ethernet/IP4, address size 6/4
  f6:09:36:23:17:70/130.140.25.2 -> 00:00:00:00:00:00/130.140.25.1
00:01:53:640214: error-drop
  arp-input: IP4 destination address not local to subnet

Packet 2

00:01:54:644159: dpdk-input
  af_packet0 rx queue 0
  buffer 0x400392f: current data 0, length 42, free-list 0, totlen-nifb 0,
trace 0x1
  PKT MBUF: port 0, nb_segs 1, pkt_len 42
buf_len 2176, data_len 42, ol_flags 0x0, data_off 128, phys_addr
0x3d6e0ac0
packet_type 0x0
  ARP: f6:09:36:23:17:70 -> ff:ff:ff:ff:ff:ff
  request, type ethernet/IP4, address size 6/4
  f6:09:36:23:17:70/130.140.25.2 -> 00:00:00:00:00:00/130.140.25.1
00:01:54:644176: ethernet-input
  ARP: f6:09:36:23:17:70 -> ff:ff:ff:ff:ff:ff
00:01:54:644199: arp-input
  request, type ethernet/IP4, address size 6/4
  f6:09:36:23:17:70/130.140.25.2 -> 00:00:00:00:00:00/130.140.25.1
00:01:54:644202: error-drop
  arp-input: IP4 destination address not local to subnet

Packet 3

00:01:56:630149: dpdk-input
  af_packet0 rx queue 0
  buffer 0x400392f: current data 0, length 42, free-list 0, totlen-nifb 0,
trace 0x2
  PKT MBUF: port 0, nb_segs 1, pkt_len 42
buf_len 2176, data_len 42, ol_flags 0x0, data_off 128, phys_addr
0x3d6e0ac0
packet_type 0x0
  ARP: f6:09:36:23:17:70 -> ff:ff:ff:ff:ff:ff
  request, type ethernet/IP4, address size 6/4
  f6:09:36:23:17:70/130.140.25.2 -> 00:00:00:00:00:00/130.140.25.1
00:01:56:642171: ethernet-input
  ARP: f6:09:36:23:17:70 -> ff:ff:ff:ff:ff:ff
00:01:56:642192: arp-input
  request, type ethernet/IP4, address size 6/4
  f6:09:36:23:17:70/130.140.25.2 -> 00:00:00:00:00:00/130.140.25.1
00:01:56:642197: error-drop
  arp-input: IP4 destination address not local to subnet

Packet 4

00:01:57:631154

Re: [vpp-dev] [dpdk-dev] dpdk/vpp and cross-version migration for vhost

[Kevin Traynor]

On 11/24/2016 06:31 AM, Yuanhan Liu wrote:
> On Tue, Nov 22, 2016 at 04:53:05PM +0200, Michael S. Tsirkin wrote:
 You keep assuming that you have the VM started first and
 figure out things afterwards, but this does not work.

 Think about a cluster of machines. You want to start a VM in
 a way that will ensure compatibility with all hosts
 in a cluster.
>>>
>>> I see. I was more considering about the case when the dst
>>> host (including the qemu and dpdk combo) is given, and
>>> then determine whether it will be a successfull migration
>>> or not.
>>>
>>> And you are asking that we need to know which host could
>>> be a good candidate before starting the migration. In such
>>> case, we indeed need some inputs from both the qemu and
>>> vhost-user backend.
>>>
>>> For DPDK, I think it could be simple, just as you said, it
>>> could be either a tiny script, or even a macro defined in
>>> the source code file (we extend it every time we add a
>>> new feature) to let the libvirt to read it. Or something
>>> else.
>>
>> There's the issue of APIs that tweak features as Maxime
>> suggested.
> 
> Yes, it's a good point.
> 
>> Maybe the only thing to do is to deprecate it,
> 
> Looks like so.
> 
>> but I feel some way for application to pass info into
>> guest might be benefitial.
> 
> The two APIs are just for tweaking feature bits DPDK supports before
> any device got connected. It's another way to disable some features
> (the another obvious way is to through QEMU command lines).
> 
> IMO, it's bit handy only in a case like: we have bunch of VMs. Instead
> of disabling something though qemu one by one, we could disable it
> once in DPDK.
> 
> But I doubt the useful of it. It's only used in DPDK's vhost example
> after all. Nor is it used in vhost pmd, neither is it used in OVS.

rte_vhost_feature_disable() is currently used in OVS, lib/netdev-dpdk.c

netdev_dpdk_vhost_class_init(void)
{
static struct ovsthread_once once = OVSTHREAD_ONCE_INITIALIZER;

/* This function can be called for different classes.  The
initialization
 * needs to be done only once */
if (ovsthread_once_start(&once)) {
rte_vhost_driver_callback_register(&virtio_net_device_ops);
rte_vhost_feature_disable(1ULL << VIRTIO_NET_F_HOST_TSO4
  | 1ULL << VIRTIO_NET_F_HOST_TSO6
  | 1ULL << VIRTIO_NET_F_CSUM);

> 
 If you don't, guest visible interface will change
 and you won't be able to migrate.

 It does not make sense to discuss feature bits specifically
 since that is not the only part of interface.
 For example, max ring size supported might change.
>>>
>>> I don't quite understand why we have to consider the max ring
>>> size here? Isn't it a virtio device attribute, that QEMU could
>>> provide such compatibility information?
>>>
>>> I mean, DPDK is supposed to support vary vring size, it's QEMU
>>> to give a specifc value.
>>
>> If backend supports s/g of any size up to 2^16, there's no issue.
> 
> I don't know others, but I see no issues in DPDK.
> 
>> ATM some backends might be assuming up to 1K s/g since
>> QEMU never supported bigger ones. We might classify this
>> as a bug, or not and add a feature flag.
>>
>> But it's just an example. There might be more values at issue
>> in the future.
> 
> Yeah, maybe. But we could analysis it one by one.
> 
 Let me describe how it works in qemu/libvirt.
 When you install a VM, you can specify compatibility
 level (aka "machine type"), and you can query the supported compatibility
 levels. Management uses that to find the supported compatibility
 and stores the compatibility in XML that is migrated with the VM.
 There's also a way to find the latest level which is the
 default unless overridden by user, again this level
 is recorded and then
 - management can make sure migration destination is compatible
 - management can avoid migration to hosts without that support
>>>
>>> Thanks for the info, it helps.
>>>
>>> ...
 As version here is an opaque string for libvirt and qemu,
 anything can be used - but I suggest either a list
 of values defining the interface, e.g.
 any_layout=on,max_ring=256
 or a version including the name and vendor of the backend,
 e.g. "org.dpdk.v4.5.6".
>>>
>>> The version scheme may not be ideal here. Assume a QEMU is supposed
>>> to work with a specific DPDK version, however, user may disable some
>>> newer features through qemu command line, that it also could work with
>>> an elder DPDK version. Using the version scheme will not allow us doing
>>> such migration to an elder DPDK version. The MTU is a lively example
>>> here? (when MTU feature is provided by QEMU but is actually disabled
>>> by user, that it could also work with an elder DPDK without MTU support).
>>>
>>> --yliu
>>
>> OK, so does a list of values look better to you then?
> 
>

Re: [vpp-dev] omg,vlan sub-interface seems not working

[Damjan Marion (damarion)]

Please use VPP native af_packet implementation. It works
in interrupt mode and interfaces can be created during runtime.

```
create host-interface name 
```

is all you need.


On 24 Nov 2016, at 09:09, Chillance Zen 
mailto:chillance...@gmail.com>> wrote:

Hi,Damjan:

here is the trace output,it iterates that vpp can not find the ip address which 
is to be resolved,but I've already configured it on the vlan-sub interface 
already.

  
130.140.25.1/24
DBGvpp# trace add dpdk-input 5
DBGvpp# show trace
--- Start of thread 0 vpp_main ---
Packet 1

00:01:53:640161: dpdk-input
  af_packet0 rx queue 0
  buffer 0x400392f: current data 0, length 42, free-list 0, totlen-nifb 0, 
trace 0x0
  PKT MBUF: port 0, nb_segs 1, pkt_len 42
buf_len 2176, data_len 42, ol_flags 0x0, data_off 128, phys_addr 0x3d6e0ac0
packet_type 0x0
  ARP: f6:09:36:23:17:70 -> ff:ff:ff:ff:ff:ff
  request, type ethernet/IP4, address size 6/4
  f6:09:36:23:17:70/130.140.25.2 -> 
00:00:00:00:00:00/130.140.25.1
00:01:53:640183: ethernet-input
  ARP: f6:09:36:23:17:70 -> ff:ff:ff:ff:ff:ff
00:01:53:640210: arp-input
  request, type ethernet/IP4, address size 6/4
  f6:09:36:23:17:70/130.140.25.2 -> 
00:00:00:00:00:00/130.140.25.1
00:01:53:640214: error-drop
  arp-input: IP4 destination address not local to subnet

Packet 2

00:01:54:644159: dpdk-input
  af_packet0 rx queue 0
  buffer 0x400392f: current data 0, length 42, free-list 0, totlen-nifb 0, 
trace 0x1
  PKT MBUF: port 0, nb_segs 1, pkt_len 42
buf_len 2176, data_len 42, ol_flags 0x0, data_off 128, phys_addr 0x3d6e0ac0
packet_type 0x0
  ARP: f6:09:36:23:17:70 -> ff:ff:ff:ff:ff:ff
  request, type ethernet/IP4, address size 6/4
  f6:09:36:23:17:70/130.140.25.2 -> 
00:00:00:00:00:00/130.140.25.1
00:01:54:644176: ethernet-input
  ARP: f6:09:36:23:17:70 -> ff:ff:ff:ff:ff:ff
00:01:54:644199: arp-input
  request, type ethernet/IP4, address size 6/4
  f6:09:36:23:17:70/130.140.25.2 -> 
00:00:00:00:00:00/130.140.25.1
00:01:54:644202: error-drop
  arp-input: IP4 destination address not local to subnet

Packet 3

00:01:56:630149: dpdk-input
  af_packet0 rx queue 0
  buffer 0x400392f: current data 0, length 42, free-list 0, totlen-nifb 0, 
trace 0x2
  PKT MBUF: port 0, nb_segs 1, pkt_len 42
buf_len 2176, data_len 42, ol_flags 0x0, data_off 128, phys_addr 0x3d6e0ac0
packet_type 0x0
  ARP: f6:09:36:23:17:70 -> ff:ff:ff:ff:ff:ff
  request, type ethernet/IP4, address size 6/4
  f6:09:36:23:17:70/130.140.25.2 -> 
00:00:00:00:00:00/130.140.25.1
00:01:56:642171: ethernet-input
  ARP: f6:09:36:23:17:70 -> ff:ff:ff:ff:ff:ff
00:01:56:642192: arp-input
  request, type ethernet/IP4, address size 6/4
  f6:09:36:23:17:70/130.140.25.2 -> 
00:00:00:00:00:00/130.140.25.1
00:01:56:642197: error-drop
  arp-input: IP4 destination address not local to subnet

DBGvpp# show trace
--- Start of thread 0 vpp_main ---
Packet 1

00:01:53:640161: dpdk-input
  af_packet0 rx queue 0
  buffer 0x400392f: current data 0, length 42, free-list 0, totlen-nifb 0, 
trace 0x0
  PKT MBUF: port 0, nb_segs 1, pkt_len 42
buf_len 2176, data_len 42, ol_flags 0x0, data_off 128, phys_addr 0x3d6e0ac0
packet_type 0x0
  ARP: f6:09:36:23:17:70 -> ff:ff:ff:ff:ff:ff
  request, type ethernet/IP4, address size 6/4
  f6:09:36:23:17:70/130.140.25.2 -> 
00:00:00:00:00:00/130.140.25.1
00:01:53:640183: ethernet-input
  ARP: f6:09:36:23:17:70 -> ff:ff:ff:ff:ff:ff
00:01:53:640210: arp-input
  request, type ethernet/IP4, address size 6/4
  f6:09:36:23:17:70/130.140.25.2 -> 
00:00:00:00:00:00/130.140.25.1
00:01:53:640214: error-drop
  arp-input: IP4 destination address not local to subnet

Packet 2

00:01:54:644159: dpdk-input
  af_packet0 rx queue 0
  buffer 0x400392f: current data 0, length 42, free-list 0, totlen-nifb 0, 
trace 0x1
  PKT MBUF: port 0, nb_segs 1, pkt_len 42
buf_len 2176, data_len 42, ol_flags 0x0, data_off 128, phys_addr 0x3d6e0ac0
packet_type 0x0
  ARP: f6:09:36:23:17:70 -> ff:ff:ff:ff:ff:ff
  request, type ethernet/IP4, address size 6/4
  f6:09:36:23:17:70/130.140.25.2 -> 
00:00:00:00:00:00/130.140.25.1
00:01:54:644176: ethernet-input
  ARP: f6:09:36:23:17:70 -> ff:ff:ff:ff:ff:ff
00:01:54:644199: arp-input
  request, type ethernet/IP4, address size 6/4
  f6:09:36:23:17:70/130.140.25.2 -> 
00:00:00:00:00:00/130.140.25.1
00:01:54:644202: error-drop
  arp-input: IP4 destination address not local to subnet

Packet 3

00:01:56:630149: dpdk-input

[vpp-dev] native vhost-user perf improvements

[Damjan Marion (damarion)]

I know that several people are playing with VPP vhost-user implementation
so just a heads-up about latest change in master which really helps 
with NDR performance. We are observing NDR gain of 41% in our testbeds.

https://git.fd.io/vpp/commit/?id=4e969f9

Let me know if any issues, or just feedback how it works.

Thanks,

Damjan



___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] [vpp] does vpp support interface hotplugin?

[Damjan Marion]

> On 24 Nov 2016, at 08:51, yu scott  wrote:
> 
> Hi Marion,
> 
> Does next release version  support hotplugins?
> BTW, hotplugins is very importance for VPP used for NFV.

I’m not aware of any planned effort to do that, but contributions are welcome…

Thanks,

Damjan___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] flowtable plugin

[Damjan Marion]

both opaque and opaque2 are shared resource. There is no guarantee that node in 
the middle will not overwrite it.

Is your situation really a case where node A needs to send some information to 
node C and there is 
unknown B or many Bs in the middle?


> On 23 Nov 2016, at 15:15, gannega  wrote:
> 
> Thanks for the explanation.
> 
> So I can use anything I want within the opaque buffer as long as I don't
> presume what happens next.
> 
> And ... I'm actually doing things I should not in the flowtable (which
> wasn't obvious to me until you explained it that way) ... so I'll go fix
> that.
> 
> 
> Thanks again,
> 
> Best regards,
> 
> 
> On 11/23/16 14:55, Keith Burns wrote:
>> 
>> 
>> On Wed, Nov 23, 2016 at 5:23 AM gannega > 
>> >> wrote:
>> 
>>Hi Keith,
>> 
>>This is a kind reminder.
>> 
>> 
>> Apologies for tardiness...
>> 
>> 
>>Also, I stumbled upon VPP-320, and especially
>>https://gerrit.fd.io/r/#/c/1676/ which adds a 6 Bytes of
>>plugin_metadata
>>in the opaque1 union, which has been reopened for nsh-proxy.
>> 
>> 
>> I guess the real issue here is that we should only presume the
>> existence of things that we know to exist :-P (Oohm, tree
>> falling in the woods, sound of one hand clapping).
>> 
>> Simply put, lets assume nodes A -> B -> C -> D (in that order).
>> 
>> Ideally opaque metadata from node A -> "something else" should only
>> tell "something else" about some kind of state from node A.
>> 
>> ie node A writes into opaque "the state of A is red" with the
>> intention that this means something to a later node (ie node C drops
>> packets when state is "red")
>> 
>> What it should avoid doing is:
>> 
>> node A writes into opaque "node C should do this".
>> 
>> In the case where node C is a plugin, which are by definition
>> "optional", this should be verboten.
>> 
>> At some point we may want to add/subtract nodes from the graph post
>> run-time init. If we have a scheme that assumes the existence of some
>> later node "bad things" (tm) will happen, IMHO.
>> 
>> So node A exists, (Cogito, ergo sum... or maybe "Puto esse ego"  - I
>> think I exist?) therefore it's ok for it to say things about it's
>> state or the things preceding it.
>> 
>> 
>>I feel this might be a good way to go which would ensure no collision
>>between the uses of the flowtable and the rest of vpp (if such was
>>indeed your fear).
>> 
>> 
>> Collisions can be avoided with interface feature awareness, no ?
>> 
>> 
> 
> --
> Gabriel Ganne
> 
> This message and any attachments (the "message") are confidential, intended 
> solely for the addressees. If you are not the intended recipient, please 
> notify the sender immediately by e-mail and delete this message from your 
> system. In this case, you are not authorized to use, copy this message and/or 
> disclose the content to any other person. E-mails are susceptible to 
> alteration. Neither Qosmos nor any of its subsidiaries or affiliates shall be 
> liable for the message if altered, changed or falsified.
> 
> Ce message et toutes ses pièces jointes (ci-après le "message")sont 
> confidentiels et établis à l'intention exclusive de ses destinataires. Si 
> vous avez reçu ce message par erreur, merci d’en informer immédiatement son 
> émetteur par courrier électronique et d’effacer ce message de votre système. 
> Dans cette hypothèse, vous n’êtes pas autorisé à utiliser, copier ce message 
> et/ou en divulguer le contenu à un tiers. Tout message électronique est 
> susceptible d'altération. Qosmos et ses filiales déclinent toute 
> responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié.
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io 
> https://lists.fd.io/mailman/listinfo/vpp-dev 
> 
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] flowtable plugin

[gannega]

The flowtable uses the opaque buffer for two things:
- it provides a flow id, and a flow state
- it provides an opaque buffer to be filled with information external to
vpp (which in my case is dpi metadatas, but it could be anything) using
the binary API.

So the flowtable (node A) alone will provides flow-level information,
but does not do anything with them, and any other subsequent node (node
C) can make use of this data.

In my specific use case, there is nothing between A and C, and all the
packets go from A to C.
But, if a node B were to overwrite the data written by the flowtable,
then it would be up to C to know it and act consequently, right ?

Regards,

On 11/24/16 12:36, Damjan Marion wrote:
>
> both opaque and opaque2 are shared resource. There is no guarantee
> that node in the middle will not overwrite it.
>
> Is your situation really a case where node A needs to send some
> information to node C and there is
> unknown B or many Bs in the middle?
>
>
>> On 23 Nov 2016, at 15:15, gannega > > wrote:
>>
>> Thanks for the explanation.
>>
>> So I can use anything I want within the opaque buffer as long as I don't
>> presume what happens next.
>>
>> And ... I'm actually doing things I should not in the flowtable (which
>> wasn't obvious to me until you explained it that way) ... so I'll go fix
>> that.
>>
>>
>> Thanks again,
>>
>> Best regards,
>>
>>
>> On 11/23/16 14:55, Keith Burns wrote:
>>>
>>>
>>> On Wed, Nov 23, 2016 at 5:23 AM gannega >> 
>>> > wrote:
>>>
>>>Hi Keith,
>>>
>>>This is a kind reminder.
>>>
>>>
>>> Apologies for tardiness...
>>>
>>>
>>>Also, I stumbled upon VPP-320, and especially
>>>https://gerrit.fd.io/r/#/c/1676/ which adds a 6 Bytes of
>>>plugin_metadata
>>>in the opaque1 union, which has been reopened for nsh-proxy.
>>>
>>>
>>> I guess the real issue here is that we should only presume the
>>> existence of things that we know to exist :-P (Oohm, tree
>>> falling in the woods, sound of one hand clapping).
>>>
>>> Simply put, lets assume nodes A -> B -> C -> D (in that order).
>>>
>>> Ideally opaque metadata from node A -> "something else" should only
>>> tell "something else" about some kind of state from node A.
>>>
>>> ie node A writes into opaque "the state of A is red" with the
>>> intention that this means something to a later node (ie node C drops
>>> packets when state is "red")
>>>
>>> What it should avoid doing is:
>>>
>>> node A writes into opaque "node C should do this".
>>>
>>> In the case where node C is a plugin, which are by definition
>>> "optional", this should be verboten.
>>>
>>> At some point we may want to add/subtract nodes from the graph post
>>> run-time init. If we have a scheme that assumes the existence of some
>>> later node "bad things" (tm) will happen, IMHO.
>>>
>>> So node A exists, (Cogito, ergo sum... or maybe "Puto esse ego"  - I
>>> think I exist?) therefore it's ok for it to say things about it's
>>> state or the things preceding it.
>>>
>>>
>>>I feel this might be a good way to go which would ensure no collision
>>>between the uses of the flowtable and the rest of vpp (if such was
>>>indeed your fear).
>>>
>>>
>>> Collisions can be avoided with interface feature awareness, no ?
>>>
>>>
>>
>> --
>> Gabriel Ganne
>>
>> This message and any attachments (the "message") are confidential,
>> intended solely for the addressees. If you are not the intended
>> recipient, please notify the sender immediately by e-mail and delete
>> this message from your system. In this case, you are not authorized
>> to use, copy this message and/or disclose the content to any other
>> person. E-mails are susceptible to alteration. Neither Qosmos nor any
>> of its subsidiaries or affiliates shall be liable for the message if
>> altered, changed or falsified.
>>
>> Ce message et toutes ses pièces jointes (ci-après le "message")sont
>> confidentiels et établis à l'intention exclusive de ses
>> destinataires. Si vous avez reçu ce message par erreur, merci d’en
>> informer immédiatement son émetteur par courrier électronique et
>> d’effacer ce message de votre système. Dans cette hypothèse, vous
>> n’êtes pas autorisé à utiliser, copier ce message et/ou en divulguer
>> le contenu à un tiers. Tout message électronique est susceptible
>> d'altération. Qosmos et ses filiales déclinent toute responsabilité
>> au titre de ce message s'il a été altéré, déformé ou falsifié.
>> ___
>> vpp-dev mailing list
>> vpp-dev@lists.fd.io 
>> https://lists.fd.io/mailman/listinfo/vpp-dev
>

--
Gabriel Ganne

This message and any attachments (the "message") are confidential, intended 
solely for the addressees. If you are not the intended recipient, please notify 
the sender immediately by e-mail and delete this message from your system. In 
this case, you are not authorized t

Re: [vpp-dev] [dpdk-dev] dpdk/vpp and cross-version migration for vhost

[Yuanhan Liu]

On Thu, Nov 24, 2016 at 09:30:49AM +, Kevin Traynor wrote:
> On 11/24/2016 06:31 AM, Yuanhan Liu wrote:
> > On Tue, Nov 22, 2016 at 04:53:05PM +0200, Michael S. Tsirkin wrote:
>  You keep assuming that you have the VM started first and
>  figure out things afterwards, but this does not work.
> 
>  Think about a cluster of machines. You want to start a VM in
>  a way that will ensure compatibility with all hosts
>  in a cluster.
> >>>
> >>> I see. I was more considering about the case when the dst
> >>> host (including the qemu and dpdk combo) is given, and
> >>> then determine whether it will be a successfull migration
> >>> or not.
> >>>
> >>> And you are asking that we need to know which host could
> >>> be a good candidate before starting the migration. In such
> >>> case, we indeed need some inputs from both the qemu and
> >>> vhost-user backend.
> >>>
> >>> For DPDK, I think it could be simple, just as you said, it
> >>> could be either a tiny script, or even a macro defined in
> >>> the source code file (we extend it every time we add a
> >>> new feature) to let the libvirt to read it. Or something
> >>> else.
> >>
> >> There's the issue of APIs that tweak features as Maxime
> >> suggested.
> > 
> > Yes, it's a good point.
> > 
> >> Maybe the only thing to do is to deprecate it,
> > 
> > Looks like so.
> > 
> >> but I feel some way for application to pass info into
> >> guest might be benefitial.
> > 
> > The two APIs are just for tweaking feature bits DPDK supports before
> > any device got connected. It's another way to disable some features
> > (the another obvious way is to through QEMU command lines).
> > 
> > IMO, it's bit handy only in a case like: we have bunch of VMs. Instead
> > of disabling something though qemu one by one, we could disable it
> > once in DPDK.
> > 
> > But I doubt the useful of it. It's only used in DPDK's vhost example
> > after all. Nor is it used in vhost pmd, neither is it used in OVS.
> 
> rte_vhost_feature_disable() is currently used in OVS, lib/netdev-dpdk.c

Hmmm. I must have checked very old code ...
> 
> netdev_dpdk_vhost_class_init(void)
> {
> static struct ovsthread_once once = OVSTHREAD_ONCE_INITIALIZER;
> 
> /* This function can be called for different classes.  The
> initialization
>  * needs to be done only once */
> if (ovsthread_once_start(&once)) {
> rte_vhost_driver_callback_register(&virtio_net_device_ops);
> rte_vhost_feature_disable(1ULL << VIRTIO_NET_F_HOST_TSO4
>   | 1ULL << VIRTIO_NET_F_HOST_TSO6
>   | 1ULL << VIRTIO_NET_F_CSUM);

I saw the commit introduced such change, but it tells no reason why
it was added.

commit 362ca39639ae871806be5ae97d55e1cbb14afd92
Author: mweglicx 
Date:   Thu Apr 14 17:40:06 2016 +0100

Update relevant artifacts to add support for DPDK 16.04.

Following changes are applied:
 - INSTALL.DPDK.md: CONFIG_RTE_BUILD_COMBINE_LIBS step has been
   removed because it is no longer present in DPDK configuration
   (combined library is created by default),
 - INSTALL.DPDK.md: VHost Cuse configuration is updated,
 - netdev-dpdk.c: Link speed definition is changed in DPDK and
   netdev_dpdk_get_features is updated accordingly,
 - netdev-dpdk.c: TSO and checksum offload has been disabled for
   vhostuser device.
 - .travis/linux-build.sh: DPDK version is updated and legacy
   flags have been removed in configuration.

Signed-off-by: Michal Weglicki 
Signed-off-by: Panu Matilainen 
Acked-by: Daniele Di Proietto 

--yliu
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] VPP Compilation Issue on Centos

[Sreejith Surendran Nair]

Hi Christophe,

Thanks a lot for the help. I tried reinstalling the VPP package and tried
the above steps the compilation worked successfully.


Unfortunately after running the VPP start service it did not start properly
I got an error with respect to "dpdk not enough free huge pages".


Could you please help and suggest if I am missing anything.


*Error Logs:*
---

[root@localhost vpp]# sudo service vpp start
Redirecting to /bin/systemctl start  vpp.service

[root@localhost vpp]# sudo service vpp status -l
Redirecting to /bin/systemctl status  -l vpp.service
● vpp.service - Vector Packet Processing Process
   Loaded: loaded (/usr/lib/systemd/system/vpp.service; disabled; vendor
preset: disabled)
   Active: inactive (dead)

Nov 24 08:02:54 localhost.localdomain vpp[28713]:
vlib_plugin_early_init:213: plugin path /usr/lib/vpp_plugins
Nov 24 08:02:54 localhost.localdomain vpp[28713]: load_one_plugin:92:
Loaded plugin: /usr/lib/vpp_plugins/ila_plugin.so
Nov 24 08:02:54 localhost.localdomain vpp[28713]: load_one_plugin:92:
Loaded plugin: /usr/lib/vpp_plugins/ioam_e2e_plugin.so
Nov 24 08:02:54 localhost.localdomain vpp[28713]: load_one_plugin:92:
Loaded plugin: /usr/lib/vpp_plugins/ioam_export_plugin.so
Nov 24 08:02:54 localhost.localdomain vpp[28713]: load_one_plugin:92:
Loaded plugin: /usr/lib/vpp_plugins/ioam_pot_plugin.so
Nov 24 08:02:54 localhost.localdomain vpp[28713]: load_one_plugin:92:
Loaded plugin: /usr/lib/vpp_plugins/ioam_trace_plugin.so
Nov 24 08:02:54 localhost.localdomain vpp[28713]: load_one_plugin:92:
Loaded plugin: /usr/lib/vpp_plugins/lb_plugin.so
Nov 24 08:02:54 localhost.localdomain vpp[28713]: load_one_plugin:92:
Loaded plugin: /usr/lib/vpp_plugins/libsixrd_plugin.so
Nov 24 08:02:54 localhost.localdomain vpp[28713]: load_one_plugin:92:
Loaded plugin: /usr/lib/vpp_plugins/snat_plugin.so




*Nov 24 08:02:54 localhost.localdomain vpp[28713]: vpp[28713]: dpdk_config:
not enough free huge pages[root@localhost vpp]#*

*Vpp startup config:*-

unix {
  nodaemon
  log /tmp/vpp.log
  full-coredump
}

dpdk {
uio-driver uio_pci_generic
}

api-trace {
  on
}

api-segment {
  gid vpp
}

"/etc/vpp/startup.conf" 18L, 144


Thanks & Regards,
Sreejith

On 24 November 2016 at 02:51, Christophe FONTAINE <
christophe.fonta...@qosmos.com> wrote:

> Hi,
>
>
>
> Did you installed all dependencies thru ‘make install-dep’ first ?
>
> On a fresh centos7 system / platform, I always do:
>
> -  export PLATFORM=’’ (default
> is ‘vpp’)
>
> -  make bootstrap
>
> -  make install-dep
>
> -  make pkg-rpm
>
>
>
> Christophe
>
>
>
>
>
> *From:* vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] *On
> Behalf Of *Sreejith Surendran Nair
> *Sent:* jeudi 24 novembre 2016 07:10
> *To:* vpp-dev 
> *Subject:* [vpp-dev] VPP Compilation Issue on Centos
>
>
>
> Hi Team,
>
> I am using Centos 7 to build the VPP package but while running the vagrant
> build command I getting the below error with respect to Kernel headers ( no
> such file or directory).
>
> Could you please help and suggest if possible.
>
>
> [root@localhost 3.10.0-123.el7.x86_64]# uname -r
> 3.10.0-123.el7.x86_64
>
> Error:
> 
> [root@localhost 3.10.0-123.el7.x86_64]# ./build-root/vagrant/build.sh
>
> == Build lib/librte_eal/linuxapp/eal
> == Build lib/librte_eal/linuxapp/igb_uio
> *make: *** /lib/modules/3.10.0-123.el7.x86_64/build: No such file or
> directory.  Stop.*
> make[11]: *** [igb_uio.ko] Error 2
> make[10]: *** [igb_uio] Error 2
> make[10]: *** Waiting for unfinished jobs
>   CC eal.o
>   CC eal_hugepage_info.o
>   CC eal_memory.o
>   CC eal_thread.o
>   CC eal_log.o
>   CC eal_vfio.o
>   CC eal_vfio_mp_sync.o
>   CC eal_pci.o
>   CC eal_pci_uio.o
>   CC eal_pci_vfio.o
>   CC eal_debug.o
>   CC eal_lcore.o
>   CC eal_timer.o
>   CC eal_interrupts.o
>   CC eal_alarm.o
>   CC eal_common_lcore.o
>   CC eal_common_timer.o
>   CC eal_common_memzone.o
>   CC eal_common_log.o
>   CC eal_common_launch.o
>   CC eal_common_pci.o
>   CC eal_common_pci_uio.o
>   CC eal_common_memory.o
>   CC eal_common_tailqs.o
>   CC eal_common_cpuflags.o
>   CC eal_common_errno.o
>   CC eal_common_string_fns.o
>   CC eal_common_hexdump.o
>   CC eal_common_devargs.o
>   CC eal_common_dev.o
>   CC eal_common_options.o
>   CC eal_common_thread.o
>   CC eal_common_proc.o
>   CC rte_malloc.o
>   CC malloc_elem.o
>   CC malloc_heap.o
>   CC rte_keepalive.o
>   CC rte_cpuflags.o
>   CC rte_spinlock.o
>   SYMLINK-FILE include/exec-env/rte_interrupts.h
>   SYMLINK-FILE include/exec-env/rte_kni_common.h
>   SYMLINK-FILE include/exec-env/rte_dom0_common.h
>   AR librte_eal.a
>   INSTALL-LIB librte_eal.a
> make[9]: *** [linuxapp] Error 2
> make[8]: *** [librte_eal] Error 2
> make[7]: *** [lib] Error 2
> make[6]: *** [all] Error 2
> make[5]: *** [pre_install] Error 2
> make[4]: *** [install] Error 2
> make[4]: Leaving directory `/home/techmahindra/source_
> vpp/vpp/build-root/build-vpp-native/dpdk

Re: [vpp-dev] [dpdk-dev] dpdk/vpp and cross-version migration for vhost

[Maxime Coquelin]

On 11/24/2016 01:33 PM, Yuanhan Liu wrote:

On Thu, Nov 24, 2016 at 09:30:49AM +, Kevin Traynor wrote:

> On 11/24/2016 06:31 AM, Yuanhan Liu wrote:

> > On Tue, Nov 22, 2016 at 04:53:05PM +0200, Michael S. Tsirkin wrote:

>  You keep assuming that you have the VM started first and
>  figure out things afterwards, but this does not work.
> 
>  Think about a cluster of machines. You want to start a VM in
>  a way that will ensure compatibility with all hosts
>  in a cluster.

> >>>
> >>> I see. I was more considering about the case when the dst
> >>> host (including the qemu and dpdk combo) is given, and
> >>> then determine whether it will be a successfull migration
> >>> or not.
> >>>
> >>> And you are asking that we need to know which host could
> >>> be a good candidate before starting the migration. In such
> >>> case, we indeed need some inputs from both the qemu and
> >>> vhost-user backend.
> >>>
> >>> For DPDK, I think it could be simple, just as you said, it
> >>> could be either a tiny script, or even a macro defined in
> >>> the source code file (we extend it every time we add a
> >>> new feature) to let the libvirt to read it. Or something
> >>> else.

> >>
> >> There's the issue of APIs that tweak features as Maxime
> >> suggested.

> >
> > Yes, it's a good point.
> >

> >> Maybe the only thing to do is to deprecate it,

> >
> > Looks like so.
> >

> >> but I feel some way for application to pass info into
> >> guest might be benefitial.

> >
> > The two APIs are just for tweaking feature bits DPDK supports before
> > any device got connected. It's another way to disable some features
> > (the another obvious way is to through QEMU command lines).
> >
> > IMO, it's bit handy only in a case like: we have bunch of VMs. Instead
> > of disabling something though qemu one by one, we could disable it
> > once in DPDK.
> >
> > But I doubt the useful of it. It's only used in DPDK's vhost example
> > after all. Nor is it used in vhost pmd, neither is it used in OVS.

>
> rte_vhost_feature_disable() is currently used in OVS, lib/netdev-dpdk.c

Hmmm. I must have checked very old code ...

>
> netdev_dpdk_vhost_class_init(void)
> {
> static struct ovsthread_once once = OVSTHREAD_ONCE_INITIALIZER;
>
> /* This function can be called for different classes.  The
> initialization
>  * needs to be done only once */
> if (ovsthread_once_start(&once)) {
> rte_vhost_driver_callback_register(&virtio_net_device_ops);
> rte_vhost_feature_disable(1ULL << VIRTIO_NET_F_HOST_TSO4
>   | 1ULL << VIRTIO_NET_F_HOST_TSO6
>   | 1ULL << VIRTIO_NET_F_CSUM);

I saw the commit introduced such change, but it tells no reason why
it was added.


I'm also interested to know the reason.
In any case, I think this is something that can/should be managed by
the management tool, which  should disable it in cmd parameters.

Kevin, do you agree?

Cheers,
Maxime
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] VPP Compilation Issue on Centos

[Dave Barach (dbarach)]

Check the number of hugetlb pages: cat /proc/sys/vm/nr_hugepages. Rough guess, 
repeated compilations have fragmented memory to the point where the minimum 
number of hugetlb pages is not available.

A reboot with the vpp packages installed should cure the problem.

Thanks… Dave

From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Sreejith Surendran Nair
Sent: Thursday, November 24, 2016 8:27 AM
To: Christophe FONTAINE 
Cc: vpp-dev ; Rashiqa Jameel -X (rajameel - TECH MAHINDRA 
LIM at Cisco) 
Subject: Re: [vpp-dev] VPP Compilation Issue on Centos

Hi Christophe,
Thanks a lot for the help. I tried reinstalling the VPP package and tried the 
above steps the compilation worked successfully.

Unfortunately after running the VPP start service it did not start properly I 
got an error with respect to "dpdk not enough free huge pages".

Could you please help and suggest if I am missing anything.

Error Logs:
---

[root@localhost vpp]# sudo service vpp start
Redirecting to /bin/systemctl start  vpp.service

[root@localhost vpp]# sudo service vpp status -l
Redirecting to /bin/systemctl status  -l vpp.service
● vpp.service - Vector Packet Processing Process
   Loaded: loaded (/usr/lib/systemd/system/vpp.service; disabled; vendor 
preset: disabled)
   Active: inactive (dead)

Nov 24 08:02:54 localhost.localdomain vpp[28713]: vlib_plugin_early_init:213: 
plugin path /usr/lib/vpp_plugins
Nov 24 08:02:54 localhost.localdomain vpp[28713]: load_one_plugin:92: Loaded 
plugin: /usr/lib/vpp_plugins/ila_plugin.so
Nov 24 08:02:54 localhost.localdomain vpp[28713]: load_one_plugin:92: Loaded 
plugin: /usr/lib/vpp_plugins/ioam_e2e_plugin.so
Nov 24 08:02:54 localhost.localdomain vpp[28713]: load_one_plugin:92: Loaded 
plugin: /usr/lib/vpp_plugins/ioam_export_plugin.so
Nov 24 08:02:54 localhost.localdomain vpp[28713]: load_one_plugin:92: Loaded 
plugin: /usr/lib/vpp_plugins/ioam_pot_plugin.so
Nov 24 08:02:54 localhost.localdomain vpp[28713]: load_one_plugin:92: Loaded 
plugin: /usr/lib/vpp_plugins/ioam_trace_plugin.so
Nov 24 08:02:54 localhost.localdomain vpp[28713]: load_one_plugin:92: Loaded 
plugin: /usr/lib/vpp_plugins/lb_plugin.so
Nov 24 08:02:54 localhost.localdomain vpp[28713]: load_one_plugin:92: Loaded 
plugin: /usr/lib/vpp_plugins/libsixrd_plugin.so
Nov 24 08:02:54 localhost.localdomain vpp[28713]: load_one_plugin:92: Loaded 
plugin: /usr/lib/vpp_plugins/snat_plugin.so
Nov 24 08:02:54 localhost.localdomain vpp[28713]: vpp[28713]: dpdk_config: not 
enough free huge pages
[root@localhost vpp]#

Vpp startup config:
-

unix {
  nodaemon
  log /tmp/vpp.log
  full-coredump
}

dpdk {
uio-driver uio_pci_generic
}

api-trace {
  on
}

api-segment {
  gid vpp
}

"/etc/vpp/startup.conf" 18L, 144

Thanks & Regards,
Sreejith

On 24 November 2016 at 02:51, Christophe FONTAINE 
mailto:christophe.fonta...@qosmos.com>> wrote:
Hi,

Did you installed all dependencies thru ‘make install-dep’ first ?
On a fresh centos7 system / platform, I always do:

-  export PLATFORM=’’ (default is 
‘vpp’)

-  make bootstrap

-  make install-dep

-  make pkg-rpm

Christophe


From: vpp-dev-boun...@lists.fd.io 
[mailto:vpp-dev-boun...@lists.fd.io] On 
Behalf Of Sreejith Surendran Nair
Sent: jeudi 24 novembre 2016 07:10
To: vpp-dev mailto:vpp-dev@lists.fd.io>>
Subject: [vpp-dev] VPP Compilation Issue on Centos

Hi Team,
I am using Centos 7 to build the VPP package but while running the vagrant 
build command I getting the below error with respect to Kernel headers ( no 
such file or directory).
Could you please help and suggest if possible.

[root@localhost 3.10.0-123.el7.x86_64]# uname -r
3.10.0-123.el7.x86_64
Error:

[root@localhost 3.10.0-123.el7.x86_64]# ./build-root/vagrant/build.sh

== Build lib/librte_eal/linuxapp/eal
== Build lib/librte_eal/linuxapp/igb_uio
make: *** /lib/modules/3.10.0-123.el7.x86_64/build: No such file or directory.  
Stop.
make[11]: *** [igb_uio.ko] Error 2
make[10]: *** [igb_uio] Error 2
make[10]: *** Waiting for unfinished jobs
  CC eal.o
  CC eal_hugepage_info.o
  CC eal_memory.o
  CC eal_thread.o
  CC eal_log.o
  CC eal_vfio.o
  CC eal_vfio_mp_sync.o
  CC eal_pci.o
  CC eal_pci_uio.o
  CC eal_pci_vfio.o
  CC eal_debug.o
  CC eal_lcore.o
  CC eal_timer.o
  CC eal_interrupts.o
  CC eal_alarm.o
  CC eal_common_lcore.o
  CC eal_common_timer.o
  CC eal_common_memzone.o
  CC eal_common_log.o
  CC eal_common_launch.o
  CC eal_common_pci.o
  CC eal_common_pci_uio.o
  CC eal_common_memory.o
  CC eal_common_tailqs.o
  CC eal_common_cpuflags.o
  CC eal_common_errno.o
  CC eal_common_string_fns.o
  CC eal_common_hexdump.o
  CC eal_common_devargs.o
  CC eal_common_dev.o
  CC eal_common_options.o
  CC eal_common_thread.o
  CC eal_common_proc.o
  CC rte_malloc.o
  CC malloc_elem.o
  CC malloc_heap.o
  CC rte_keepalive.o
  CC rte_cpuflags.o
  CC rte_spi

Re: [vpp-dev] [dpdk-dev] dpdk/vpp and cross-version migration for vhost

[Kevin Traynor]

On 11/24/2016 12:47 PM, Maxime Coquelin wrote:
> 
> 
> On 11/24/2016 01:33 PM, Yuanhan Liu wrote:
>> On Thu, Nov 24, 2016 at 09:30:49AM +, Kevin Traynor wrote:
>>> > On 11/24/2016 06:31 AM, Yuanhan Liu wrote:
 > > On Tue, Nov 22, 2016 at 04:53:05PM +0200, Michael S. Tsirkin wrote:
>>> >  You keep assuming that you have the VM started first and
>>> >  figure out things afterwards, but this does not work.
>>> > 
>>> >  Think about a cluster of machines. You want to start a VM in
>>> >  a way that will ensure compatibility with all hosts
>>> >  in a cluster.
>> > >>>
>> > >>> I see. I was more considering about the case when the dst
>> > >>> host (including the qemu and dpdk combo) is given, and
>> > >>> then determine whether it will be a successfull migration
>> > >>> or not.
>> > >>>
>> > >>> And you are asking that we need to know which host could
>> > >>> be a good candidate before starting the migration. In such
>> > >>> case, we indeed need some inputs from both the qemu and
>> > >>> vhost-user backend.
>> > >>>
>> > >>> For DPDK, I think it could be simple, just as you said, it
>> > >>> could be either a tiny script, or even a macro defined in
>> > >>> the source code file (we extend it every time we add a
>> > >>> new feature) to let the libvirt to read it. Or something
>> > >>> else.
> > >>
> > >> There's the issue of APIs that tweak features as Maxime
> > >> suggested.
 > >
 > > Yes, it's a good point.
 > >
> > >> Maybe the only thing to do is to deprecate it,
 > >
 > > Looks like so.
 > >
> > >> but I feel some way for application to pass info into
> > >> guest might be benefitial.
 > >
 > > The two APIs are just for tweaking feature bits DPDK supports
 before
 > > any device got connected. It's another way to disable some features
 > > (the another obvious way is to through QEMU command lines).
 > >
 > > IMO, it's bit handy only in a case like: we have bunch of VMs.
 Instead
 > > of disabling something though qemu one by one, we could disable it
 > > once in DPDK.
 > >
 > > But I doubt the useful of it. It's only used in DPDK's vhost
 example
 > > after all. Nor is it used in vhost pmd, neither is it used in OVS.
>>> >
>>> > rte_vhost_feature_disable() is currently used in OVS,
>>> lib/netdev-dpdk.c
>> Hmmm. I must have checked very old code ...
>>> >
>>> > netdev_dpdk_vhost_class_init(void)
>>> > {
>>> > static struct ovsthread_once once = OVSTHREAD_ONCE_INITIALIZER;
>>> >
>>> > /* This function can be called for different classes.  The
>>> > initialization
>>> >  * needs to be done only once */
>>> > if (ovsthread_once_start(&once)) {
>>> > rte_vhost_driver_callback_register(&virtio_net_device_ops);
>>> > rte_vhost_feature_disable(1ULL << VIRTIO_NET_F_HOST_TSO4
>>> >   | 1ULL << VIRTIO_NET_F_HOST_TSO6
>>> >   | 1ULL << VIRTIO_NET_F_CSUM);
>> I saw the commit introduced such change, but it tells no reason why
>> it was added.
> 
> I'm also interested to know the reason.

I can't remember off hand, added Mark K or Michal W who should be able
to shed some light on it.

> In any case, I think this is something that can/should be managed by
> the management tool, which  should disable it in cmd parameters.
> 
> Kevin, do you agree?

I think best to find out the reason first. Because if no reason to
disable in the code, then no need to debate!

> 
> Cheers,
> Maxime

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] [dpdk-dev] dpdk/vpp and cross-version migration for vhost

[Kavanagh, Mark B]

>
>On 11/24/2016 12:47 PM, Maxime Coquelin wrote:
>>
>>
>> On 11/24/2016 01:33 PM, Yuanhan Liu wrote:
>>> On Thu, Nov 24, 2016 at 09:30:49AM +, Kevin Traynor wrote:
 > On 11/24/2016 06:31 AM, Yuanhan Liu wrote:
> > > On Tue, Nov 22, 2016 at 04:53:05PM +0200, Michael S. Tsirkin wrote:
 >  You keep assuming that you have the VM started first and
 >  figure out things afterwards, but this does not work.
 > 
 >  Think about a cluster of machines. You want to start a VM in
 >  a way that will ensure compatibility with all hosts
 >  in a cluster.
>>> > >>>
>>> > >>> I see. I was more considering about the case when the dst
>>> > >>> host (including the qemu and dpdk combo) is given, and
>>> > >>> then determine whether it will be a successfull migration
>>> > >>> or not.
>>> > >>>
>>> > >>> And you are asking that we need to know which host could
>>> > >>> be a good candidate before starting the migration. In such
>>> > >>> case, we indeed need some inputs from both the qemu and
>>> > >>> vhost-user backend.
>>> > >>>
>>> > >>> For DPDK, I think it could be simple, just as you said, it
>>> > >>> could be either a tiny script, or even a macro defined in
>>> > >>> the source code file (we extend it every time we add a
>>> > >>> new feature) to let the libvirt to read it. Or something
>>> > >>> else.
>> > >>
>> > >> There's the issue of APIs that tweak features as Maxime
>> > >> suggested.
> > >
> > > Yes, it's a good point.
> > >
>> > >> Maybe the only thing to do is to deprecate it,
> > >
> > > Looks like so.
> > >
>> > >> but I feel some way for application to pass info into
>> > >> guest might be benefitial.
> > >
> > > The two APIs are just for tweaking feature bits DPDK supports
> before
> > > any device got connected. It's another way to disable some features
> > > (the another obvious way is to through QEMU command lines).
> > >
> > > IMO, it's bit handy only in a case like: we have bunch of VMs.
> Instead
> > > of disabling something though qemu one by one, we could disable it
> > > once in DPDK.
> > >
> > > But I doubt the useful of it. It's only used in DPDK's vhost
> example
> > > after all. Nor is it used in vhost pmd, neither is it used in OVS.
 >
 > rte_vhost_feature_disable() is currently used in OVS,
 lib/netdev-dpdk.c
>>> Hmmm. I must have checked very old code ...
 >
 > netdev_dpdk_vhost_class_init(void)
 > {
 > static struct ovsthread_once once = OVSTHREAD_ONCE_INITIALIZER;
 >
 > /* This function can be called for different classes.  The
 > initialization
 >  * needs to be done only once */
 > if (ovsthread_once_start(&once)) {
 > rte_vhost_driver_callback_register(&virtio_net_device_ops);
 > rte_vhost_feature_disable(1ULL << VIRTIO_NET_F_HOST_TSO4
 >   | 1ULL << VIRTIO_NET_F_HOST_TSO6
 >   | 1ULL << VIRTIO_NET_F_CSUM);
>>> I saw the commit introduced such change, but it tells no reason why
>>> it was added.
>>
>> I'm also interested to know the reason.
>
>I can't remember off hand, added Mark K or Michal W who should be able
>to shed some light on it.

DPDK v16.04 added support for vHost User TSO; as such, by default, TSO is 
advertised to guest devices as an available feature during feature negotiation 
with QEMU.
However, while the vHost user backend sets up the majority of the mbuf fields 
that are required for TSO, there is still a reliance on the associated DPDK 
application (i.e. in this case OvS-DPDK) to set the remaining flags and/or 
offsets. Since OvS-DPDK doesn't currently provide that functionality, it is 
necessary to explicitly disable TSO; otherwise, undefined behaviour will ensue.

>
>> In any case, I think this is something that can/should be managed by
>> the management tool, which  should disable it in cmd parameters.
>>
>> Kevin, do you agree?
>
>I think best to find out the reason first. Because if no reason to
>disable in the code, then no need to debate!
>
>>
>> Cheers,
>> Maxime

___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] How to transfer packets between 2 bridge domains ?

[Christophe FONTAINE]

Hi,

I’m working on Tap as a Service feature for OpenStack [1], and I hope I just 
don’t know how to configure VPP to transfer packets between 2 bridge domains.
The global setup follows the blueprint [2], but basically, here is what I have :

VhostUser0/0/1
   |
span
   |
loop0   loop1
   |   |
[BD-A] === [BD-B]--VhostUser0/0/2
|
   Gigabit/0/0/1.3901

Booth bridge domains are configured to flood the traffic.
This 2 bridge domain setup is required to be able to have the traffic from1 
spanned interface (named tap-flow) copied to multiple destination (named 
tap-service), as well as multiple tap-flows to a single tap-service.

The problem I have is that I can't use 2 loopback interfaces with a cross 
connect because the xconnect feature:
- is tied to the device-input feature mask: when incoming packets are flooded 
by the bridge, the packets are sent to interface-out, and to not go thru the rx 
path
- as it is tied to the device-input feature mask, we can't have xconnect AND 
bridge features enabled at the same time.
Same problem with the l2patch.

I tried different things, such as using the input and output classifiers to 
redirect packets to the appropriate interface-out  (eg: loop2-tx )nodes, using 
the same vhost user socket as client and server to loopback the traffic from 2 
bridge domains, using 2 sub-interfaces from a loopback interface to transfer 
the packets from 1 bd to the other, but I think I'm missing something important 
!
The only way I got this working was by using an external veth pair, each end 
connected to 1 bd... not a real solution for me.

I thought I could write an 'xconnect-tx node' to be able to transfer the 
packets (this node would be like the output classifier ), but I wanted first to 
know whether this is the only solution.

Many thanks !
Christophe

[1] https://github.com/christophefontaine/tap-as-a-service
[2] 
https://wiki.openstack.org/wiki/Blueprint-networking-vpp-taas#Possible_implementations
This message and any attachments (the "message") are confidential, intended 
solely for the addressees. If you are not the intended recipient, please notify 
the sender immediately by e-mail and delete this message from your system. In 
this case, you are not authorized to use, copy this message and/or disclose the 
content to any other person. E-mails are susceptible to alteration. Neither 
Qosmos nor any of its subsidiaries or affiliates shall be liable for the 
message if altered, changed or falsified.

Ce message et toutes ses pièces jointes (ci-après le "message")sont 
confidentiels et établis à l'intention exclusive de ses destinataires. Si vous 
avez reçu ce message par erreur, merci d’en informer immédiatement son émetteur 
par courrier électronique et d’effacer ce message de votre système. Dans cette 
hypothèse, vous n’êtes pas autorisé à utiliser, copier ce message et/ou en 
divulguer le contenu à un tiers. Tout message électronique est susceptible 
d'altération. Qosmos et ses filiales déclinent toute responsabilité au titre de 
ce message s'il a été altéré, déformé ou falsifié.
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] How to transfer packets between 2 bridge domains ?

[Christophe FONTAINE]

Continuing my investigation on l2_xcrw, I'm wondering why the 
L2OUTPUT_FEAT_XCRW is never set, on the contrary of the other output features 
(CLASSIFY, ACL) ?

Also, I don't understand why we need to do a xconnect between the source 
interface and the xcrw0 ?
Wouldn't the next node be set thanks to 'feat_bitmap_get_next_node_index'  
called by l2_output_dispatch ?
This would render the xconnect a duplicate, as well as this xconnect forbid the 
interface to be part of a bridge.

Christophe

> -Original Message-
> From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On
> Behalf Of Christophe FONTAINE
> Sent: jeudi 24 novembre 2016 20:23
> To: vpp-dev@lists.fd.io
> Subject: [vpp-dev] How to transfer packets between 2 bridge domains ?
>
> Hi,
>
> I’m working on Tap as a Service feature for OpenStack [1], and I hope I just
> don’t know how to configure VPP to transfer packets between 2 bridge
> domains.
> The global setup follows the blueprint [2], but basically, here is what I 
> have :
>
> VhostUser0/0/1
>|
> span
>|
> loop0   loop1
>|   |
> [BD-A] === [BD-B]--VhostUser0/0/2
> |
>Gigabit/0/0/1.3901
>
> Booth bridge domains are configured to flood the traffic.
> This 2 bridge domain setup is required to be able to have the traffic from1
> spanned interface (named tap-flow) copied to multiple destination (named
> tap-service), as well as multiple tap-flows to a single tap-service.
>
> The problem I have is that I can't use 2 loopback interfaces with a cross
> connect because the xconnect feature:
> - is tied to the device-input feature mask: when incoming packets are
> flooded by the bridge, the packets are sent to interface-out, and to not go
> thru the rx path
> - as it is tied to the device-input feature mask, we can't have xconnect AND
> bridge features enabled at the same time.
> Same problem with the l2patch.
>
> I tried different things, such as using the input and output classifiers to
> redirect packets to the appropriate interface-out  (eg: loop2-tx )nodes, using
> the same vhost user socket as client and server to loopback the traffic from 2
> bridge domains, using 2 sub-interfaces from a loopback interface to transfer
> the packets from 1 bd to the other, but I think I'm missing something
> important !
> The only way I got this working was by using an external veth pair, each end
> connected to 1 bd... not a real solution for me.
>
> I thought I could write an 'xconnect-tx node' to be able to transfer the
> packets (this node would be like the output classifier ), but I wanted first 
> to
> know whether this is the only solution.
>
> Many thanks !
> Christophe
>
> [1] https://github.com/christophefontaine/tap-as-a-service
> [2] https://wiki.openstack.org/wiki/Blueprint-networking-vpp-
> taas#Possible_implementations
> This message and any attachments (the "message") are confidential,
> intended solely for the addressees. If you are not the intended recipient,
> please notify the sender immediately by e-mail and delete this message
> from your system. In this case, you are not authorized to use, copy this
> message and/or disclose the content to any other person. E-mails are
> susceptible to alteration. Neither Qosmos nor any of its subsidiaries or
> affiliates shall be liable for the message if altered, changed or falsified.
>
> Ce message et toutes ses pièces jointes (ci-après le "message")sont
> confidentiels et établis à l'intention exclusive de ses destinataires. Si vous
> avez reçu ce message par erreur, merci d’en informer immédiatement son
> émetteur par courrier électronique et d’effacer ce message de votre
> système. Dans cette hypothèse, vous n’êtes pas autorisé à utiliser, copier ce
> message et/ou en divulguer le contenu à un tiers. Tout message
> électronique est susceptible d'altération. Qosmos et ses filiales déclinent
> toute responsabilité au titre de ce message s'il a été altéré, déformé ou
> falsifié.
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
This message and any attachments (the "message") are confidential, intended 
solely for the addressees. If you are not the intended recipient, please notify 
the sender immediately by e-mail and delete this message from your system. In 
this case, you are not authorized to use, copy this message and/or disclose the 
content to any other person. E-mails are susceptible to alteration. Neither 
Qosmos nor any of its subsidiaries or affiliates shall be liable for the 
message if altered, changed or falsified.

Ce message et toutes ses pièces jointes (ci-après le "message")sont 
confidentiels et établis à l'intention exclusive de ses destinataires. Si vous 
avez reçu ce message par erreur, merci d’en informer immédiatement son émetteur 
par courrier électronique et d’effacer ce message de votre système. Dans cette 
h

Re: [vpp-dev] [vpp] does vpp support interface hotplugin?

[yu scott]

Hi Christophe，
If run vpp in vm, vm is used as router in openstack vnf
,when create a subnet and the subnet need connect router.
the router need hot plugin a interface for the subnet

2016-11-24 16:02 GMT+08:00 Christophe FONTAINE <
christophe.fonta...@qosmos.com>:

> Hi Yu,
>
>
>
> Could you give me an example of the requirement of the physical hotplug
> for NFV ?
>
> FYI, vhost-user is already implemented: using VPP as a vswitch already
> works, so, hotplug of virtual interfaces already works.
>
>
>
> The way I see this is:
>
> -  SRIOV/PCI pass thru: vpp is not in the loop, and the physical
> interfaces are reserved, and connected to the VMs
>
> -  VPP as a vswitch: you connect all your physical interfaces at
> startup, and your vms are connected to vpp thru vhost-user socket.
>
>
>
> Christophe
>
>
>
> *From:* vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] *On
> Behalf Of *yu scott
> *Sent:* jeudi 24 novembre 2016 08:52
> *To:* vpp-dev@lists.fd.io
> *Subject:* Re: [vpp-dev] [vpp] does vpp support interface hotplugin?
>
>
>
> Hi *Marion,*
>
>
>
> *Does next release version  support hotplugins?*
>
> *BTW, hotplugins is very importance for VPP used for NFV.*
>
>
>
> 2016-11-24 4:13 GMT+08:00 Damjan Marion :
>
>
> > On 17 Nov 2016, at 03:07, Chillance Zen  wrote:
> >
> >
> > Hi, dear all.
> > as far as I know , vpp is derived from cisco 's mature commercial
> > product,since accelerated with DPDK,it's very suitable for VNF appliance
> > ,and also this is what we are gonna do.one thing which confuses me is how
> > vpp supports plugable interface to make vpp more flexible since we do not
> > restart vpp when a interface joins vpp.what's more ,DPDK does support
> port
> > hotplugin with both pci dev and vdev.
>
> We currently do not support hotplug of physical devices. It is not
> impossible
> to add support but it will require some work...
>
> ___
> vpp-dev mailing list
> vpp-dev@lists.fd.io
> https://lists.fd.io/mailman/listinfo/vpp-dev
>
>
>
> This message and any attachments (the "message") are confidential,
> intended solely for the addressees. If you are not the intended recipient,
> please notify the sender immediately by e-mail and delete this message from
> your system. In this case, you are not authorized to use, copy this message
> and/or disclose the content to any other person. E-mails are susceptible to
> alteration. Neither Qosmos nor any of its subsidiaries or affiliates shall
> be liable for the message if altered, changed or falsified.
>
> Ce message et toutes ses pièces jointes (ci-après le "message")sont
> confidentiels et établis à l'intention exclusive de ses destinataires. Si
> vous avez reçu ce message par erreur, merci d’en informer immédiatement son
> émetteur par courrier électronique et d’effacer ce message de votre
> système. Dans cette hypothèse, vous n’êtes pas autorisé à utiliser, copier
> ce message et/ou en divulguer le contenu à un tiers. Tout message
> électronique est susceptible d'altération. Qosmos et ses filiales déclinent
> toute responsabilité au titre de ce message s'il a été altéré, déformé ou
> falsifié.
>
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev