[vpp-dev] Ping utility in VPP

[Nagaprabhanjan Bellaru]

Hi,

I am not sure if the ping debug CLI is being actively used, but the
function "init_icmp46_echo_request" goes ahead and writes 2000 bytes into
the vlib_buffer corrupting the surrounding memory area. After 3-4 pings,
vpp always crashes.

Instead of copying sizeof(icmp_echo_request->data) which is 2000, it we
copy just data_len to the buffer, it should be fine?

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

[vpp-dev] VPP-616 VPP Vagrant default box -> puppetlabs Ubuntu 16.04

[Dave Wallace]

Keith,

Please test the following patch for compatibility with your VMWare 
configuration: https://gerrit.fd.io/r/#/c/4897


@Damjan, I think that this should be cherry-picked to 17.01 since Ubuntu 
14.04 is likely to deprecated.  What do you think?


Note: I also changed the default behavior to run "make test" instead of 
building the deb|rpm packages.


FYI, here is the commit message:
 %< 
Update default Vagrant box to Ubuntu 16.04, VPP-616

- Make puppetlabs/ubuntu-16.04-64-nocm the default box
- Enable x11 forwarding
- Install x11-utils required for emacs to work over X11
- Change default build to run "make test" instead of building packages

Change-Id: I0ec054fdc83feb71ca8396df53ed02bf82ecd7e7
Signed-off-by: Dave Wallace 
 %< 

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

Re: [vpp-dev] [csit-dev] vpp make test for verify - are we there yet ? [awoken]

[Dave Wallace]

Klement/Neale,

I finally got back to debugging this issue.  After doing a make 
test-wipe, then make test.  The patched python files and their 
corresponding .pyc files had the same timestamp with a 1-second 
resolution.  I deleted all .pyc files and then all of the tests passed.  
After doing some research, I confirmed that python uses a 1-second 
resolution when checking whether to recompile the *.pyc file.


I have verified that the following patch resolves this issue both on 
Ubuntu 16.04 in Vagrant and Ubuntu 16.10 on bare metal:


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

Thanks,
-daw-

On 01/05/2017 03:54 AM, Klement Sekera -X (ksekera - PANTHEON 
TECHNOLOGIES at Cisco) wrote:

Dave, there is no sign of test framework installing/patching scapy in
the log you provided.

Could you please do in the same workspace

make test-wipe

and then run the make test again? I don't think it'll actually help us,
because there should be no way for a python inside virtualenv to get its
hands on outside libs (unless there is a bug of course), but let's see
what happens...

Thanks,
Klement

Quoting Dave Wallace (2017-01-04 19:19:04)

Neale,

I could not find scapy installed in the normal path (i.e. "which scapy"),
but I'm not sure if it is directly executable.  You can find the "V=1
TEST=mpls make test" output on
vagrant+virtualbox:puppetlabs/ubuntu-16.04.64-nocm in this pastebin doc:
[1]http://pastebin.com/uGAUREhK

Thanks,
-daw-

On 1/4/2017 10:59 AM, Neale Ranns (nranns) wrote:

   


  Hi,

   


  The reason the MPLS tests are failing is because scapy cannot decode an
  MPLS label stack (output from some .show() instrumentation);

   


  

  ###[ Ethernet ]###

dst   = 02:01:00:00:ff:02

src   = 02:fe:e5:05:0e:13

type  = 0x8847

  ###[ MPLS ]###

   label = 33L

   cos   = 0L

   s = 0L   << NON End-of-stack

   ttl   = 254

  ###[ Padding ]###

  load  = '\x00\x061\xffE\x00\x00#\x00\x01\x00\x00@\x11
  \xa6\xac\x10\x01\x01\xac\x10\x01\x02\x04\xd2\x04\xd2\x00\x0f\xd0\x92257
  1 1'

   


  we patch scapy for this purpose, see;

/test/patches/scapy-2.3.3/mpls.py.patch

   


  on my vagrant 14.04 there is no other scapy installation, this patch
  applies fine and all MPLS tests pass.

  On a UCS 14.04, with another scapy installation:

/usr/local/lib/python2.7/dist-packages/scapy/contrib/mpls.py

  the MPLS test fail.

  On a UCS 16.04 no scpay installation, tests pass.

   


  Do you have scapy installed in the machines on which the tests
  fail/pass? Or am I barking up the wrong virtualenv tree J

   


  Thanks,

  neale

   

   

   


From: Dave Wallace [2]
Date: Wednesday, 4 January 2017 at 15:38
To: "Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)"
[3], "Maciek Konstantynowicz (mkonstan)"
[4], "Neale Ranns (nranns)" [5]
Cc: [6]"csit-...@lists.fd.io" [7],
[8]"vpp-dev@lists.fd.io" [9]
Subject: Re: [csit-dev] [vpp-dev] vpp make test for verify - are we
there yet ? [awoken]

 


Klement,

I'm in the process of modifying the base Vagrantfile/build scripts to
replace building the VPP native package and installing it in the VM to
simply running "make test" which takes much less time.  All of the
test runs that I have performed are clean builds on a virgin git clone
repo.

That being said, I'll give the "git clean -dfX */" a try and see if I
get different results on the 2nd pass and report back.

Thanks,
-daw-

On 1/4/17 10:23 AM, Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES
at Cisco) wrote:

  Hi Dave,

   


  could you please try running git clean -dfX */ in a workspace, where you see

  the failures, and then givet it another try? For me this seems to clear issues

  up. Damjans recent changes might have caused (quoting Damjan) "major

  disturbances in the force", leaving build artifacts behind.

   


  Just be sure to stash/commit any changes you have in the workspace since

  the git clean nukes everything unknown from the ws.

   


  Thanks,

  Klement

   


  Quoting Dave Wallace (2017-01-04 16:12:38)

 As I mentioned on the VPP call yesterday, I'm seeing what appears to be

 the same GRE test failures on Ubuntu 16.10 (bare metal).  I'm also seeing

 the same failures on vagrant+virtualbox with

 puppetlabs/ubuntu-16.04.64-nocm. I also am getting failures on 3 out of 4

 MPLS tests on both environments.

   


 However, all tests pass on vagrant+virtualbox with

 

Re: [vpp-dev] SNAT Plugin Use

[Jon Loeliger]

On Wed, Jan 25, 2017 at 10:49 AM, Dave Barach (dbarach) 
wrote:
>
>
>
> When it comes time to send binary API messages to a given plugin, the
> control-plane agent recovers msg_id_base like so:
>
>
>
>   /* Ask the vpp engine for the first assigned message-id */
>
>   name = format (0, "snat_%08x%c", api_version, 0);
>
>   sm->msg_id_base = vl_client_get_first_plugin_msg_id ((char *) name);
>
>
>
> and adds it to the enumerated message id values:
>
>
>
>   mp->_vl_msg_id = ntohs (msg_id_base + VL_API_some_msg_id);
>
>
>
> Since the set of plugins can change between runs, absolute message ID’s
> can’t be guaranteed.
>
>
>
> Thanks… Dave
>

Does this same mechanism hold true for the VPE messages?  Is the collection
of the VPE message considered "a plugin", or "a base onto which plugins will
be added"?  There are currently 20 or 21 include files' worth of msg ids
here.

Specifically, I'm trying to resolve an understanding of what I was told to
do
last week (Use a msg_id based on a lookup of "_") versus this
use a msg_id obtained by "base + enum-value".

Is there a plugin name for the VPE collection of API msg ids?  (I don't
think so.)
Will these msg_ids always be 0-based so no base offset need be looked-up
nor added?

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

Re: [vpp-dev] SNAT Plugin Use

[Dave Barach (dbarach)]

Dear Jon,

Here’s the business end of snat_msg_enum.h:

#define vl_msg_id(n,h) n,
typedef enum {
#include 
/* We'll want to know how many messages IDs we need... */
VL_MSG_FIRST_AVAILABLE,
} vl_msg_id_t;
#undef vl_msg_id

This will cause the problem you’ve mentioned. So, don’t use it!

Make your own:

#define vl_msg_id(n,h) n,
typedef enum {
#include 
} snat_msg_id_t;

typedef enum {
#include 
} another_plugin_msg_id_t



#undef vl_msg_id

This will give you multiple overlapping enums. You’ll have to add the indicated 
plugin message ID block base, as described earlier.

You could also go for the one-minute-manager easy way to solve the problem: use 
the message-name + crc hash table, just like the python language binding does.

Take a look at the generated snat.api.h:

/** Message name, crc list **/

#ifdef vl_msg_name_crc_list
#define foreach_vl_msg_name_crc_snat \
_(VL_API_SNAT_ADD_ADDRESS_RANGE, snat_add_address_range, 689a7cae) \
_(VL_API_SNAT_ADD_ADDRESS_RANGE_REPLY, snat_add_address_range_reply, 7d360766) \
_(VL_API_SNAT_ADDRESS_DUMP, snat_address_dump, 27c92402) \
_(VL_API_SNAT_ADDRESS_DETAILS, snat_address_details, a86ec839)


You could do something like so:

#define _(a,b,c) static char *STR_##a=#b##_#c;
#define vl_msg_name_crc_list
#include 
#include 
...
#endif

Which resolves to ‘static char 
*STR_VL_API_SNAT_ADD_ADDRESS_RANGE=”snat_add_address_range_””689a7cae”;’.

Then:

   VL_API_SNAT_ADD_ADDRESS_RANGE_MSG_ID = vl_api_get_msg_index 
(STR_VL_API_SNAT_ADD_ADDRESS_RANGE);

HTH... D.

From: Jon Loeliger [mailto:j...@netgate.com]
Sent: Thursday, January 26, 2017 3:29 PM
To: Dave Barach (dbarach) 
Cc: vpp-dev 
Subject: Re: [vpp-dev] SNAT Plugin Use



On Wed, Jan 25, 2017 at 10:49 AM, Dave Barach (dbarach) 
> wrote:
Dear Jon,

Sorry for the delayed response.

Anyhow, the constant VL_MSG_FIRST_AVAILABLE is a historical name for a simple 
thing: the number of binary API messages defined by a given plugin.

Understood.

I’m not sure what you’re trying to do, but it’s actually just as well that you 
ran into a compile error. I need to explain a number of details so you won’t 
end up seriously annoyed after wasting a bunch of your time.

Hrm.  Maybe too late for that... :-)

So, let me give a bit of insight into what I am doing, because I think
my intent may be being misunderstood a little.

I am doing what I suspect might be the obvious Use Case for the C API
to VPP lib.  Effectively we are are writing a totally different CLI front-end
to VPP through the VPP lib API.  We are strictly *using* vlib -- we are not,
at this time, writing any new plugin to VPP, nor are we extending VPP's
functionality via a new plugin.

However, we have need to use multiple plugins.  If you consider the "vpe"
pieces one plugin, then currently our next plug we need is SNAT.

When the vpp data-plane loads plugins, each plugin which defines a binary API 
is expected to do something like the following:

  name = format (0, "snat_%08x%c", api_version, 0);

  /* Ask for a correctly-sized block of API message decode slots */
  sm->msg_id_base = vl_msg_api_get_msg_ids
  ((char *) name, VL_MSG_FIRST_AVAILABLE);

The data-plane plugin asks for a block of message-ID’s. 
vl_msg_api_get_msg_ids(...) makes a string-hash entry, to map the string 
_ to the base of the message-id block.

OK, good.  I get that, I believe.

When it comes time to send binary API messages to a given plugin, the 
control-plane agent recovers msg_id_base like so:

  /* Ask the vpp engine for the first assigned message-id */
  name = format (0, "snat_%08x%c", api_version, 0);
  sm->msg_id_base = vl_client_get_first_plugin_msg_id ((char *) name);

and adds it to the enumerated message id values:

  mp->_vl_msg_id = ntohs (msg_id_base + VL_API_some_msg_id);

This is the code that we can't currently write.  I have need of both the
interface and SNAT APIs in one C source file.  In that case, I had intended
to make both interface and SNAT API message calls.  I'm happy to offset
the number scheme for one of these sets, or both, by an offset.  But I
can't include both of the msg_id enumberations in the same C file because
they collide on the definition of the VL_MSG_FIRST_AVAILABLE as found
in the enum definitions.

Are we expected to have to interface to each plugin from a separate C
source file?  I can add an extra set of routines to hide all this in an 
additional
C source file if needed, I guess.

Would it make more sense for these enums to provide VL_MSG_ID_SNAT_N_MSGS
or something unique to that enum?

Also, is there an API call to "load" a plugin that I missed somewhere?   How 
does
my main-line code tell VLIB that the SNAT plugin will need to be loaded?


Since the set of plugins can change between runs, absolute message ID’s can’t 
be guaranteed.

Yep, I get that too.  Where is all this plugin stuff described?  I see, for 
example,
the "sample" plugin 

Re: [vpp-dev] SNAT Plugin Use

[Jon Loeliger]

On Wed, Jan 25, 2017 at 10:49 AM, Dave Barach (dbarach) 
wrote:

> Dear Jon,
>
>
>
> Sorry for the delayed response.
>
>
>
> Anyhow, the constant VL_MSG_FIRST_AVAILABLE is a historical name for a
> simple thing: the number of binary API messages defined by a given plugin.
>

Understood.


> I’m not sure what you’re trying to do, but it’s actually just as well that
> you ran into a compile error. I need to explain a number of details so you
> won’t end up seriously annoyed after wasting a bunch of your time.
>

Hrm.  Maybe too late for that... :-)

So, let me give a bit of insight into what I am doing, because I think
my intent may be being misunderstood a little.

I am doing what I suspect might be the obvious Use Case for the C API
to VPP lib.  Effectively we are are writing a totally different CLI
front-end
to VPP through the VPP lib API.  We are strictly *using* vlib -- we are not,
at this time, writing any new plugin to VPP, nor are we extending VPP's
functionality via a new plugin.

However, we have need to use multiple plugins.  If you consider the "vpe"
pieces one plugin, then currently our next plug we need is SNAT.

When the vpp data-plane loads plugins, each plugin which defines a binary
> API is expected to do something like the following:
>
>
>
>   name = format (0, "snat_%08x%c", api_version, 0);
>
>
>
>   /* Ask for a correctly-sized block of API message decode slots */
>
>   sm->msg_id_base = vl_msg_api_get_msg_ids
>
>   ((char *) name, VL_MSG_FIRST_AVAILABLE);
>
>
>
> The data-plane plugin asks for a block of message-ID’s.
> vl_msg_api_get_msg_ids(...) makes a string-hash entry, to map the string
> _ to the base of the message-id block.
>

OK, good.  I get that, I believe.


> When it comes time to send binary API messages to a given plugin, the
> control-plane agent recovers msg_id_base like so:
>
>
>
>   /* Ask the vpp engine for the first assigned message-id */
>
>   name = format (0, "snat_%08x%c", api_version, 0);
>
>   sm->msg_id_base = vl_client_get_first_plugin_msg_id ((char *) name);
>
>
>
> and adds it to the enumerated message id values:
>
>
>
>   mp->_vl_msg_id = ntohs (msg_id_base + VL_API_some_msg_id);
>

This is the code that we can't currently write.  I have need of both the
interface and SNAT APIs in one C source file.  In that case, I had intended
to make both interface and SNAT API message calls.  I'm happy to offset
the number scheme for one of these sets, or both, by an offset.  But I
can't include both of the msg_id enumberations in the same C file because
they collide on the definition of the VL_MSG_FIRST_AVAILABLE as found
in the enum definitions.

Are we expected to have to interface to each plugin from a separate C
source file?  I can add an extra set of routines to hide all this in an
additional
C source file if needed, I guess.

Would it make more sense for these enums to provide VL_MSG_ID_SNAT_N_MSGS
or something unique to that enum?

Also, is there an API call to "load" a plugin that I missed somewhere?
How does
my main-line code tell VLIB that the SNAT plugin will need to be loaded?


Since the set of plugins can change between runs, absolute message ID’s
> can’t be guaranteed.
>

Yep, I get that too.  Where is all this plugin stuff described?  I see, for
example,
the "sample" plugin src/examples/sample-plugin/sample/.  However, I think
that
describes how to write a new plugin to extend VPP's functionality.   That's
not
what I'm doing.

Please let me know if there are other questions I could answer to help
clarify what I'm trying to do here!

Thanks… Dave
>

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

Re: [vpp-dev] [deb-dpdk] igb_uio -> uio_pci_generic

[Burt Silverman]

Thanks, Christian, this is great information.

Just for fun, before I read this, I wanted to test some of my kernel
building skills. So I just wish to build modules in the drivers/vfio
directory. I want to do what might be called "building an external module"
or "building only one kernel module" as in
http://askubuntu.com/questions/515407/how-recipe-to-build-only-one-kernel-module
or "building a third party module". But the Google hits like that one
assume that you have no interest in changing the .config. And one Ubuntu
package that may be useful, linux-source, has info showing up in Synaptic
saying "you don't want this package." Here is my procedure and I hope it
works -- it is relatively painless. I'll describe it for a particular
level. I am using the desktop version of Ubuntu.

1. Install linux-headers-4.8.0-34-generic (I think it may be installed
automatically.)
2. Install linux-headers-4.8.0-34 (again, may be automatically installed.)

$ cd $HOME
$ cp -a /usr/src/linux-headers-4.8.0-34 .
$ cp -a /usr/src/linux-headers-4.8.0-34-generic .
$ cd linux-headers-4.8.0-34-generic

Now "make menuconfig" and go into drivers and then go into vfio and then go
inside there and find the interesting option to enable.

Now you need the source code for drivers/vfio. I guess the safest way is
to  install linux-source-4.8.0 and untar its linux-source-4.8.0-tar.bz into
your home directory so you end up with linux-source-4.8.0 under $HOME. When
I did my experimenting, I worked mostly from the torvalds Linux repo, at
tag v4.8.

$ cd $HOME/linux-source-4.8.0 #assuming you untarred the source from Ubuntu
here.
$ make -C $HOME/linux-headers-4.8.0-34-generic M=$(pwd)/drivers/vfio
modules #in addition to modules, you can use "clean" as appropriate

This is tricky stuff because there is plenty of non-information and
misinformation out there AND

M= #better not try relative path
O= #kernel Makefile
does not warn you clearly but it bombs

Normally I like the O option to put the built stuff away from the source.

Well, this stuff may be slightly off topic, but if I ever have to retrieve
my instructions, I'll know where to search, chuckle. And I hope they work
like they did for me. I was able to insmod a module that I built with
source from torvalds repo. I built form Ubuntu source and I assume it will
also insmod but haven't checked.

Burt

On Thu, Jan 26, 2017 at 9:00 AM, Christian Ehrhardt <
christian.ehrha...@canonical.com> wrote:

> On Wed, Jan 25, 2017 at 5:24 PM, Ed Warnicke  wrote:
>
>> Looping in the deb_dpdk and rpm_dpdk guys to see if they have thoughts on
>> how these things play out in deployment.
>>
>
> Thanks Ed.
> Adding my 2 cents inline below just to provide another POV ...
>
>
>
>> On Tue, Jan 24, 2017 at 9:05 PM, Burt Silverman  wrote:
>>
>>> Hi Damjan,
>>>
>>> My understanding is that CONFIG_VFIO_NOIOMMU will never be set in a
>>> stock kernel, and you will need to build a custom kernel for that.
>>>
>>
> Well, to Enable the config itself isn't bad until enable_unsafe_noiommu_mo
> deis set (which is default off).
> See https://patchwork.kernel.org/patch/7906971/ for a few more Details.
>
> IMHO that means it can be safely in a default kernel with support, and it
> is on the administrator to enable that mode.
> But that is like giving wrong people root, or missetting something else -
> not as bad as building an own kernel.
>
> In fact there was a guy with my name who got that enabled in the next
> Ubuntu Release Zesty :-)
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1634050
>
> For vfio (as the default) there is another thing much more in the way.
> People will likely want iommu support if possible, but in 9/10 cases I've
> seen I'd say that some oddity forced them to be unable to use it.
> Certain Firmware rendered iommu useless, Unable to set up the iommu group
> assignment correctly, ...
> I happened to get the feeling that it might only work in just one special
> Lab setup somebody has out there.
>
> The noiommu config might make that simpler, but then it throws away a lot
> that vfio should provide.
> So I'd only use it for test/devel but would not like it too much for
> production use.
>
> That said IMHO I would not suggest vfio as a default these days even with
> the kernel option enabled.
>
>
>
>> I understand that with this option, the kernel cannot guarantee that
>>> applications are prevented from creating bugs that normally the kernel can
>>> guarantee will not occur (outside of a kernel bug.) It therefore violates
>>> the fundamental Linux system design. That being said, you may wish to
>>> accept the risk for performance reasons and build a custom kernel. The
>>> other strange thing would be that MSI or MSI-X style interrupts are not
>>> needed for performance. The people who developed them have made a lot of
>>> noise about how they came about for performance reasons. I have no direct
>>> experience, but to learn that they are not important is a 

Re: [vpp-dev] building rpm packages failure

[gannega]

Hi,

I believe this happens if you still have the dpdk binaries in
build-root/install-vpp-native/dpdk/bin/ when building the vpp rpm.
The install wildcards used at the begining of the spec file are too
permissive.

I propose this simple patch :  https://gerrit.fd.io/r/#/c/4894/

Best regards,


On 01/25/17 16:55, Burt Silverman wrote:
> I ran into some strange results on Fedora 25; first there was a
> problem but it disappeared:
>
> The problem occurred when I was on master. It seemed that the '~'
> character in the filenames like you have in your note was giving the
> rpm tools a bad time. So I switched to the 17.01 branch and the
> problems disappeared. It seemed logical. But now, everything works for
> me on master. Despite having '~' in filenames, everything works. Maybe
> the tools changed when I updated my Fedora. Beats me.
>
> Burt
>
> On Wed, Jan 25, 2017 at 10:07 AM, Rybalchenko, Kirill
> >
> wrote:
>
> Building rpm packages on Fedora23 fails with the following error
> message:
>
>
>
> Processing files: vpp-debuginfo-17.04-rc0~144_ge056c8a.x86_64
>
> Provides: vpp-debuginfo = 17.04-rc0~144_ge056c8a
> vpp-debuginfo(x86-64) = 17.04-rc0~144_ge056c8a
>
> Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1
> rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
>
> Checking for unpackaged file(s): /usr/lib/rpm/check-files
> /ryback/vpp_c/build-root/rpm/BUILDROOT/vpp-17.04-rc0~144_ge056c8a.x86_64
>
> error: Installed (but unpackaged) file(s) found:
>
>/usr/bin/dpdk-pdump
>
>/usr/bin/dpdk-pmdinfo
>
>/usr/bin/dpdk-procinfo
>
>/usr/bin/testpmd
>
>
>
>
>
> RPM build errors:
>
> Macro %python2_minor_version defined but not used within scope
>
> File not found:
> 
> /ryback/vpp_c/build-root/rpm/BUILDROOT/vpp-17.04-rc0~144_ge056c8a.x86_64/usr/lib64/vpp_plugins
>
> File not found:
> 
> /ryback/vpp_c/build-root/rpm/BUILDROOT/vpp-17.04-rc0~144_ge056c8a.x86_64/usr/lib64/vpp_api_test_plugins
>
> Installed (but unpackaged) file(s) found:
>
>/usr/bin/dpdk-pdump
>
>/usr/bin/dpdk-pmdinfo
>
>/usr/bin/dpdk-procinfo
>
>/usr/bin/testpmd
>
> --
> Intel Research and Development Ireland Limited
> Registered in Ireland
> Registered Office: Collinstown Industrial Park, Leixlip, County
> Kildare
> Registered Number: 308263
>
> This e-mail and any attachments may contain confidential material
> for the sole use of the intended recipient(s). Any review or
> distribution by others is strictly prohibited. If you are not the
> intended recipient, please contact the sender and delete all copies.
>
>
> ___
> 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

--
Gabriel Ganne

This message, including attachments, is CONFIDENTIAL. It may also be privileged 
or otherwise protected by law. If you received this email by mistake, please 
let us know by reply and then delete it from your system; you should not copy 
it or disclose its contents to anyone. All messages sent to and from Enea may 
be monitored to ensure compliance with internal policies and to protect our 
business. Emails are not secure and cannot be guaranteed to be error free as 
they can be intercepted, amended, lost or destroyed, or contain viruses. The 
sender therefore does not accept liability for any errors or omissions in the 
contents of this message, which arise as a result of email transmission. Anyone 
who communicates with us by email accepts these risks.
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

Re: [vpp-dev] [deb-dpdk] igb_uio -> uio_pci_generic

[Christian Ehrhardt]

On Wed, Jan 25, 2017 at 5:24 PM, Ed Warnicke  wrote:

> Looping in the deb_dpdk and rpm_dpdk guys to see if they have thoughts on
> how these things play out in deployment.
>

Thanks Ed.
Adding my 2 cents inline below just to provide another POV ...



> On Tue, Jan 24, 2017 at 9:05 PM, Burt Silverman  wrote:
>
>> Hi Damjan,
>>
>> My understanding is that CONFIG_VFIO_NOIOMMU will never be set in a stock
>> kernel, and you will need to build a custom kernel for that.
>>
>
Well, to Enable the config itself isn't bad until enable_unsafe_noiommu_modeis
set (which is default off).
See https://patchwork.kernel.org/patch/7906971/ for a few more Details.

IMHO that means it can be safely in a default kernel with support, and it
is on the administrator to enable that mode.
But that is like giving wrong people root, or missetting something else -
not as bad as building an own kernel.

In fact there was a guy with my name who got that enabled in the next
Ubuntu Release Zesty :-)
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1634050

For vfio (as the default) there is another thing much more in the way.
People will likely want iommu support if possible, but in 9/10 cases I've
seen I'd say that some oddity forced them to be unable to use it.
Certain Firmware rendered iommu useless, Unable to set up the iommu group
assignment correctly, ...
I happened to get the feeling that it might only work in just one special
Lab setup somebody has out there.

The noiommu config might make that simpler, but then it throws away a lot
that vfio should provide.
So I'd only use it for test/devel but would not like it too much for
production use.

That said IMHO I would not suggest vfio as a default these days even with
the kernel option enabled.



> I understand that with this option, the kernel cannot guarantee that
>> applications are prevented from creating bugs that normally the kernel can
>> guarantee will not occur (outside of a kernel bug.) It therefore violates
>> the fundamental Linux system design. That being said, you may wish to
>> accept the risk for performance reasons and build a custom kernel. The
>> other strange thing would be that MSI or MSI-X style interrupts are not
>> needed for performance. The people who developed them have made a lot of
>> noise about how they came about for performance reasons. I have no direct
>> experience, but to learn that they are not important is a shock.
>>
>

I don't have good insight on the related performance impact for the
question "igb_uio -> uio_pci_generic".
But then (whatever it is worth) I usually go with uio_pci_generic and most
people I talked to did so as well (on the wider DPDK and not just VPP
stage).

But here the circle closes referring to some former statements that
"compiling the kernel on your own is a no-go"
If I'm not overlooking something - at least in all environments I touched -
igb_uio is a dpdk provided kernel module and uio_pci_generic is in the
kernel.
At least
http://dpdk.org/doc/guides/linux_gsg/build_dpdk.html#loading-modules-to-enable-userspace-io-for-dpdk
backs my memory up.

That said - loading a custom module is just as bad as building your own
kernel in terms of applicability in a real case.

So to add my unimportant opinion to this thread about what could/should be
the default:
1. uio_pci_generic (default)
2. vfio (as a better option for those who want/can set it up correctly)
3. igb_uio (fallback for special cases where it is needed)

As I said I can't participate in the performance fight between
uip_pci_generic and igb_uio



>> It seems to me that the Ubuntu 14.04 issue is really a separate one from
>> all of this, although I would imagine that the conclusion to stop
>> supporting it does not change.
>>
>> Burt
>>
>> On Tue, Jan 24, 2017 at 1:07 PM, Damjan Marion (damarion) <
>> damar...@cisco.com> wrote:
>>
>>>
>>> > On 24 Jan 2017, at 18:40, Damjan Marion (damarion) 
>>> wrote:
>>> >
>>> >>
>>> >> On 24 Jan 2017, at 18:26, Stephen Hemminger <
>>> step...@networkplumber.org> wrote:
>>> >>
>>> >> On Tue, 24 Jan 2017 17:14:42 +
>>> >> "Damjan Marion (damarion)"  wrote:
>>> >>
>>> >>> Is anybody aware of any valid reason why we cannot switch to
>>> uio_pci_generic
>>> >>> as default PCI uio driver in ubuntu packages?
>>> >>>
>>> >>> I think generally people don’t like out-of-tree modules, so as long
>>> as we are getting
>>> >>> the same service from uio_pci_generic we should use it…
>>> >>>
>>> >>> Thanks,
>>> >>>
>>> >>> Damjan
>>> >
>>> >> uio_pci_generic does not support MSI or MSI-X interrupts, only legacy
>>> INTX.
>>> >
>>> > I know but do we really care?
>>> >
>>> >>
>>> >> The preference should always be to use VFIO. Even on systems without
>>> IOMMU.
>>> >
>>> > What is the perf impact?
>>> >
>>> > Also, I just tried with kernel 4.8 on rangeley ATOM, and i got:
>>> >
>>> > [536030.250072] vfio-pci: probe of :00:14.0 failed with error -22
>>> > 

[vpp-dev] make test: heads up - handling expected API failure

[Klement Sekera -X (ksekera - PANTHEON TECHNOLOGIES at Cisco)]

Hi,

when doing API tests, sometimes it's expected that API fails. For
example, one might test adding the same configuration twice, or removing
non-existent configuration, expecting failure.

With my recent change https://gerrit.fd.io/r/#/c/4875/ merged, it's possible
to easily write these scenarios using a simple:

def test_api_fail(self):
...
with self.vapi.expect_negative_api_retval():
self.vapi.api_call()  # expected to fail

self.vapi.other_api_call()  # expected to pass

the expect_negative_api_retval() changes internal state to expect
failures, which is reverted back once the 'with' context is left. There
is also expect_zero_api_retval() mostly for sake of completness, so one
might write the above code also this way:

def test_api_fail(self):
   ...
   self.vapi.expect_negative_api_retval()
   self.vapi.api_call()  # expected to fail
   self.vapi.expect_zero_api_retval()
   self.vapi.other_api_call()  # expected to pass

I think the first one is simpler, more readable and less error prone
(because of the guaranteed expectation rollback).

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

Re: [vpp-dev] Minnowboard Turbot dual-e

[Jim Thompson]

Deliveries in March.

We had one running VPP at the DPDK Summit in August.
https://twitter.com/NetgateUSA/status/776928173804052480




On Thu, Jan 26, 2017 at 3:13 AM, Damjan Marion (damarion)
 wrote:
>
> With regards to home gateway discussion on the last call here is
> dual GigE version of Minnowboard Turbot.
>
> http://www.adiengineering.com/products/minnowboard-turbot-duale/
>
> It says availability Q3 2016 but I cannot find any place where it can be 
> ordered.
> Maybe netgate folks have more details….
>
>
> Another interesting device:
> http://www.up-board.org/upsquared/specifications-up2/
>
> Unfortunately they decided to use Realtek for both GigE ports…. :(
> ___
> 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

[vpp-dev] OpenStack networking-vpp 17.01

[Jerome Tollet (jtollet)]

Dear FD.io community,
The new version of networking-vpp, the OpenStack Neutron ML2 driver for VPP 
17.01 has been released today.
This version contains significant evolutions including the support for Security 
Groups based on VPP statefull ACLs.
Many thanks to VPP team for your support as well as people who contributed to 
networking-vpp development.

You’ll find attached the original announcement sent on the OpenStack mailing 
list.

Jerome

--- Begin Message ---
In conjunction with the release of VPP 17.01, I'd like to invite you all to try 
out networking-vpp for VPP 17.01.  VPP is a fast userspace forwarder based on 
the DPDK toolkit, and uses vector packet processing algorithms to minimise the 
CPU time spent  on each packet and maximise throughput.  networking-vpp is a 
ML2 mechanism driver that controls VPP on your control and compute hosts to 
provide fast L2 forwarding under Neutron.

The latest version has been updated to work with the new featuers of VPP 17.01, 
including security group support based on VPP's ACL functionality. 

The README [1] explains how you can try out VPP using devstack, which is now 
pleasantly simple; the devstack plugin will deploy the mechanism driver and VPP 
itself and should give you a working system with a minimum of hassle.

We plan on continuing development between now and VPP's 17.04 release in April. 
 There are several features we're planning to work on (you'll find a list in 
our RFE bugs at [2]), and we welcome anyone who would like to come help us.

Everyone is welcome to join our new biweekly IRC meetings, Monday 0800 PST = 
1600 GMT, due to start next Monday.
-- 
Ian.

[1]https://github.com/openstack/networking-vpp/blob/17.01/README.rst
[2]https://bugs.launchpad.net/networking-vpp/+bugs?orderby=milestone_name=0

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--- End Message ---
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev

[vpp-dev] Minnowboard Turbot dual-e

[Damjan Marion (damarion)]

With regards to home gateway discussion on the last call here is 
dual GigE version of Minnowboard Turbot.

http://www.adiengineering.com/products/minnowboard-turbot-duale/

It says availability Q3 2016 but I cannot find any place where it can be 
ordered.
Maybe netgate folks have more details….


Another interesting device:
http://www.up-board.org/upsquared/specifications-up2/

Unfortunately they decided to use Realtek for both GigE ports…. :(
___
vpp-dev mailing list
vpp-dev@lists.fd.io
https://lists.fd.io/mailman/listinfo/vpp-dev