[ovs-discuss] OVS fdb - MAC learning Subscription

[Kapil Adhikesavalu]

Hi,

is there a way to get notification on MACs learnt on a OVS bridge ?

i am looking for a way to get the results available in "ovs-appctl fdb/show
" as a notification/subscription.  i took a brief look at IDL, but
didn't find where will the MAC info will be internally stored to write a
monitor API for the same,

Any pointers on this would be great.

Thanks
Kapil.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

[ovs-discuss] Flow actions handling

[Kapil Adhikesavalu]

Hi,

i have the following flow rule,

*tun_id=0xfa0,in_port=10 actions=mod_vlan_vid:1,resubmit(0,2),resubmit(0,1)*

and i need to know in which order actions will be performed.

will the actions be performed in the s*ame order as mentioned* in the flow
? like

1. Modify VLAN as 1
2. then resubmit modified packet to table 2
3. then resubmit the same packet to table 1.

is it guaranteed that actions will be performed in this order? i seem to
hit a case where packet is seen in table 2 without VLAN mod.

Thanks
Kapil.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

[ovs-discuss] Maximum number of Patch port between bridges

[Kapil Adhikesavalu]

Hi,

is there a limit on maximum number of patch ports between bridges ?

Thanks
Kapil.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] Maximum number of Patch port between bridges

[Kapil Adhikesavalu]

Hi Levente,

Thanks a lot for spending your time in figuring this!

I was looking for around 1000 ports between bridges.

I also tried something similar, 2500 ports between two bridges. It became
very slow, even the show and dump commands became show. I was also using
Intel E5 series.

Took an alternate approach.

Couple of questions, related to multiprocessing.

I believe, at any of point time, only one flow can be processed in a
bridge. We can't do multiprocessing here within a bridge. Correct me if am
wrong.

But, say if I have two bridges can the flows in both bridges get executed
simultaneously?

Is there ways to improve flow processing in a single bridge by using multi
cores?

Thanks
Kapil
On 04-Jul-2016 5:20 PM, "Levente Csikor"  wrote:

> Hi,
>
> I did not find any documented limit about the number of patchports, so I
> wrote a simple script, which adds a predefined number of patchports and
> some dummy rules into the flow tables to actually have some reason for the
> whole stuff.
>
> First, I tried to add 100 and 1000 patchports between two OVS bridges. It
> was feasible, but took some time.
> Then I tried with 1 patchports, but I couldn't wait until it finished.
> After 1000 patchports, the adding procedure became slower and slower, so I
> killed the whole process (after a couple of thousands patchports the time
> OVS required for setting up one patchport was around a couple of seconds).
>
> So, as a conclusion, the question should be about its setup time. I don't
> know what your actual scenario is, but if you plan to create more
> patchports than a 1000, then there are a lot of other issues around it
> besides the number of possible patchports (setup time could last to half a
> day. What about the number of rules, will they fit? And update time becomes
> also an interesting part of such a 'networking architecture').
>
> Nevertheless, I did this investigation on an Intel(R) Xeon(R) CPU E5-2620
> 0 @ 2.00GHz (6 cores + 6 HT cores), with 64G RAM, and OVS-VSWITCHD was
> consuming all the physical cores I had.
>
> I hope I may have helped (at least a little bit :)).
>
> Cheers,
> Levente
>
>
>
> On 06/29/2016 07:04 PM, Kapil Adhikesavalu wrote:
>
> Hi,
>
> is there a limit on maximum number of patch ports between bridges ?
>
> Thanks
> Kapil.
>
>
> ___
> discuss mailing 
> listdiscuss@openvswitch.orghttp://openvswitch.org/mailman/listinfo/discuss
>
>
>
> ___
> discuss mailing list
> discuss@openvswitch.org
> http://openvswitch.org/mailman/listinfo/discuss
>
>
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] OVS fdb - MAC learning Subscription

[Kapil Adhikesavalu]

Hi Ben,

Thanks for the information. This is exactly what I was looking for.

My implementation involves around 3K dynamic MACs.

Couple of questions,

1. MAC eviction on table full. I took a look at NORMAL action Mac learning
code. It had implemented MAC eviction by giving fair share of entries for
the each port in the table.

Is there something similar available for LEARN action? I didn't find a way
to configure it.

I am concerned about the case where DOS attack is done by sending ton of
MAC on one port leading to flushing of MACs in other ports.

2. Will there be any noticeable performance difference between using action
NORMAL and LEARN. Assuming there wouldn't be too much MAC movement.

Thanks
Kapil
On 02-Jul-2016 6:27 AM, "Ben Pfaff"  wrote:

> On Mon, Jun 27, 2016 at 07:21:53PM +0530, Kapil Adhikesavalu wrote:
> > is there a way to get notification on MACs learnt on a OVS bridge ?
>
> OVS doesn't provide a way to do that.
>
> If you implement MAC learning using the "learn" action, e.g. as
> described in the OVS tutorial under the tutorial/ directory, then you
> can monitor the table that contains the learned MACs to get
> notifications when a MAC is learned or expires.
>
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] How to enable dpdk interface for OVS+DPDK on RHEL?

[Kapil Adhikesavalu]

Hi Binghan,

To add to that; you should follow the steps in
https://github.com/openvswitch/ovs/blob/master/INSTALL.DPDK.md to install
OVS + DPDK


you can also refer,
https://software.intel.com/en-us/articles/using-open-vswitch-with-dpdk-for-inter-vm-nfv-applications

Thanks
Kapil.

On Tue, Jul 5, 2016 at 1:23 PM, Levente Csikor  wrote:

> Hi,
>
> That manual is only for installing OVS and linking it to DPDK.
> However, you need to install DPDK on your own before installing OVS with
> DPDK.
>
> download DPDK from here: http://dpdk.org/download
> follow instructions for the installation procedure (not that difficult -
> less commands needed than for OVS :) ).
>
>
> For using OVS with DPDK, you need to insert the userspace IO driver
> provided by DPDK, then enable this driver on the interfaces you want to use
> with DPDK (this binding script will be available under:
> your-dpdk-directory/tools/dpdk_nic_bind.py
>
> argument --status will print out which port is used by the kernel driver
> and the dpdk driver.
>
> you could also find more details under http://dpdk.org/download on how to
> bind your interface to DPDK driver.
>
>
>
> On 07/05/2016 09:45 AM, Binghan wrote:
>
> Hi,
>
> I built OVS+DPDK from source. I use OVS 2.5.0 and DPDK 2.2.0, the build
> environment is RHEL 7.2. I try to follow this instruction,
> 
> https://github.com/openvswitch/ovs/blob/master/INSTALL.Fedora.md
> However, it reports:
> *make rpm-fedora*
> *make: *** No rule to make target `rpm-fedora'.  Stop.*
>
> So, try commands as follow,
> ./boot.sh
> ./configure
> rpmbuild -bb rhel/openvswitch-fedora.spec --with dpdk
>
> Finally, I got following RPMs,
>
> *RPMS/x86_64/openvswitch-2.5.0.el7.x86_64.rpm*
>
> *RPMS/noarch/openvswitch-2.5.0.el7.noarch.*
>
> *RPMS/noarch/python-openvswitch-2.5.0.el7.noarch.rpm*
>
> *RPMS/noarch/openvswitch-test-2.5.0.el7.noarch.rpm*
>
> *RPMS/x86_64/openvswitch-devel-2.5.0.el7.x86_64.rpm*
>
> *RPMS/x86_64/openvswitch-ovn-2.5.0.el7.x86_64.rpm*
>
> *RPMS/x86_64/openvswitch-debuginfo-2.5.0.el7.x86_64.rpm*
>
>
> Then, I installed rpm RPMS/x86_64/openvswitch-2.5.0.el7.x86_64.rpm.
>
> I can create bridge and ports, but dpdk interface does not exist.
>
> *ovs-vsctl get Open_vSwitch . iface_types*
>
> *[geneve, gre, internal, ipsec_gre, "l3gre", lisp, patch, stt, system,
> tap, vxlan ]*
>
>
> How can I enable dpdk interface or Is there anything wrong with my build
> procedure?
>
>
> BRs,
>
> Binghan
>
>
> ___
> discuss mailing 
> listdiscuss@openvswitch.orghttp://openvswitch.org/mailman/listinfo/discuss
>
>
>
> ___
> discuss mailing list
> discuss@openvswitch.org
> http://openvswitch.org/mailman/listinfo/discuss
>
>
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] Maximum number of Patch port between bridges

[Kapil Adhikesavalu]

When I tried, I used a single ovs-vsctl with all the patch ports as
arguments.

It was taking around 25 to 30 seconds for creating 5000 patch ports.

Thanks
Kapil
On 06-Jul-2016 5:29 AM, "Justin Pettit"  wrote:

>
> > On Jul 4, 2016, at 4:50 AM, Levente Csikor  wrote:
> >
> > Hi,
> >
> > I did not find any documented limit about the number of patchports, so I
> wrote a simple script, which adds a predefined number of patchports and
> some dummy rules into the flow tables to actually have some reason for the
> whole stuff.
> >
> > First, I tried to add 100 and 1000 patchports between two OVS bridges.
> It was feasible, but took some time.
> > Then I tried with 1 patchports, but I couldn't wait until it
> finished. After 1000 patchports, the adding procedure became slower and
> slower, so I killed the whole process (after a couple of thousands
> patchports the time OVS required for setting up one patchport was around a
> couple of seconds).
>
> This would be surprising to me.  How did you add the ports?  If you just
> ran a bunch of ovs-vsctl commands, it can take that long, but it shouldn't
> if you add them in a single transaction.  From the FAQ:
>
> -=-=-=-=-=-=-=-=-=-
>
> Q: I want to add thousands of ports to an Open vSwitch bridge, but
>it takes too long (minutes or hours) to do it with ovs-vsctl.  How
>can I do it faster?
>
> A: If you add them one at a time with ovs-vsctl, it can take a long
>time to add thousands of ports to an Open vSwitch bridge.  This is
>because every invocation of ovs-vsctl first reads the current
>configuration from OVSDB.  As the number of ports grows, this
>starts to take an appreciable amount of time, and when it is
>repeated thousands of times the total time becomes significant.
>
>The solution is to add the ports in one invocation of ovs-vsctl (or
>a small number of them).  For example, using bash:
>
>ovs-vsctl add-br br0
>cmds=; for i in {1..5000}; do cmds+=" -- add-port br0 p$i"; done
>ovs-vsctl $cmds
>
>takes seconds, not minutes or hours, in the OVS sandbox environment.
> -=-=-=-=-=-=-=-=-=-
>
> --Justin
>
>
> ___
> discuss mailing list
> discuss@openvswitch.org
> http://openvswitch.org/mailman/listinfo/discuss
>
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

[ovs-discuss] Flow table Eviction group

[Kapil Adhikesavalu]

Hello,

Need some help in configuring flow table eviction group.
I tried to configure the eviction group, but i am seeing some warn/errors
and didn't come across any sample commands in web.

1. Can you please share some sample commands for passing NXM_OF_IN_PORT[]
as an argument to flow_table, overflow_policy, "groups"

2. As overflow_policy=evict, by default removes the flow which is going to
expire at the earliest.
i want to configure the group in such a way, the group with the highest
number of common VLAN entries should evict first, i suppose i need to use
NXM_OF_VLAN_TCI

3. Is it possible to do flow table eviction based on the output port
instead of NXM_OF_IN_PORT ? there is no NXM_OF_OUT_PORT, so is that NO ?
The reason i am asking this is, I use "Learn" action to dynamically
create MAC learn flows; so there will be more entries with common output
port, than source VLAN or MAC, so doing eviction based on output port is
preferred ?

This is what i tried in ovs-2.5.0, i am getting following warning.
ovs-vsctl add-br kapil
ovs-vsctl -- --id=@ft  create  Flow_Table  flow_limit=5
 overflow_policy=evict group=NXM_OF_IN_PORT  -- set Bridge kapil
flow_tables=0=@ft

Warning in OVS log:  2016-07-15T09:42:35.704Z|00381|bridge|WARN|bridge
kapil table 0: error parsing 'groups' (NXM_OF_IN_PORT: missing [ looking
for field name)

root@ubuntu:~# ovs-vsctl list flow_table
_uuid   : f2d9a3b4-ee77-4bf9-b364-6f78ab9560d7
external_ids: {}
flow_limit  : 5
groups  : [NXM_OF_IN_PORT]
name: []
overflow_policy : evict
prefixes: []

Thanks
Kapil.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

[ovs-discuss] OVS+DPDK: pci_map_resource(): cannot mmap error

[Kapil Adhikesavalu]

Hello,

i am getting "EAL: pci_map_resource(): cannot mmap(18, 0x7f504000,
0x8, 0x0): Invalid argument (0x)" when i start
ovs-vswitchd.

Setup:DL360gen8 CPU:E5-2967 NIC:82599ES 10-Gigabit SFI/SFP+ (2 Port) (PCI:
slot0: 04:00.0 04:00.1)
Kernel: 4.6.4-201.fc23.x86_64 ixgbe driver: 4.2.1-k

i have installed : DPDK-16.04  & OVS 2.5.90 - enabled with DPDK

steps after installation:
=
1.  default_hugepagesz=1G hugepagesz=1G hugepages=16 hugepagesz=2M
hugepages=2048 intel_iommu=off
2.  mount -t hugetlbfs nodev /mnt/huge -o pagesize=1GB
 mount -t hugetlbfs nodev /mnt/huge_2mb -o pagesize=2MB
2. sudo modprobe uio   [note, i am not using VFIO/IOMMU - i tried with that
as well after enable iommu in grub - didnt help - got a different error]
3. tools/dpdk_nic_bind.py -b igb_uio 04:00.0
tools/dpdk_nic_bind.py -b igb_uio 04:00.1
4. mkdir -p $ovsdir/etc/openvswitch
ovsdb-tool create $ovsdir/etc/openvswitch/conf.db
$ovsdir/usr/share/openvswitch/vswitch.ovsschema

# Bring up ovsdb-server daemon
mkdir -p $ovsdir/var/run/openvswitch
export OVS_DB_SOCK=${ovsdir}/var/run/openvswitch/db.sock
$ovsdir/sbin/ovsdb-server --remote=punix:${OVS_DB_SOCK} \
   --remote=db:Open_vSwitch,Open_vSwitch,manager_options \
   --private-key=db:Open_vSwitch,SSL,private_key \
   --certificate=db:Open_vSwitch,SSL,certificate \
   --bootstrap-ca-cert=db:Open_vSwitch,SSL,ca_cert \
   --pidfile --detach --verbose=dbg

# Intialize the ovs database
$ovsdir/bin/ovs-vsctl --no-wait init
5. $ovsdir/bin/ovs-vsctl --no-wait set Open_vSwitch .
other_config:dpdk-init=true
   $ovsdir/bin/ovs-vsctl --no-wait set Open_vSwitch .
other_config:dpdk-socket-mem="1024,1024"

   # Use Core 1 for user mode ovsvswitch
   $ovsdir/bin/ovs-vsctl --no-wait set Open_vSwitch .
other_config:dpdk-lcore-mask=0x2

   # Number of memory channels on targeted platform
   $ovsdir/bin/ovs-vsctl --no-wait set Open_vSwitch .
other_config:dpdk-extra="-n 4"

6. $ovsdir/sbin/ovs-vswitchd unix:${OVS_DB_SOCK} --pidfile --verbose=dbg
--detach

Note: i also have another setup with DL360gen9, with the same
configuration(UIO) and it is working without any issues. i am not able to
isolate to what is causing this issue. Appreciate any help.

Error logs:

2016-07-31T13:15:57Z|1|reconnect|DBG|unix:/var/run/openvswitch/db.sock:
entering BACKOFF
2016-07-31T13:15:57Z|2|ovs_numa|INFO|Discovered 24 CPU cores on NUMA
node 0
2016-07-31T13:15:57Z|3|ovs_numa|INFO|Discovered 24 CPU cores on NUMA
node 1
2016-07-31T13:15:57Z|4|ovs_numa|INFO|Discovered 2 NUMA nodes and 48 CPU
cores
2016-07-31T13:15:57Z|5|reconnect|INFO|unix:/var/run/openvswitch/db.sock:
connecting...
2016-07-31T13:15:57Z|6|reconnect|DBG|unix:/var/run/openvswitch/db.sock:
entering CONNECTING
2016-07-31T13:15:57Z|7|poll_loop|DBG|wakeup due to [POLLOUT] on fd 10
(<->/var/run/openvswitch/db.sock) at lib/stream-fd.c:151
2016-07-31T13:15:57Z|8|reconnect|INFO|unix:/var/run/openvswitch/db.sock:
connected
2016-07-31T13:15:57Z|9|reconnect|DBG|unix:/var/run/openvswitch/db.sock:
entering ACTIVE
2016-07-31T13:15:57Z|00010|jsonrpc|DBG|unix:/var/run/openvswitch/db.sock:
send request, method="get_schema", params=["Open_vSwitch"], id=0
2016-07-31T13:15:57Z|00015|jsonrpc|DBG|unix:/var/run/openvswitch/db.sock:
received reply, result={"locked":true}, id=1
2016-07-31T13:15:57Z|00016|poll_loop|DBG|wakeup due to [POLLIN] on fd 10
(<->/var/run/openvswitch/db.sock) at lib/stream-fd.c:155
2016-07-31T13:15:57Z|00017|jsonrpc|DBG|unix:/var/run/openvswitch/db.sock:
received reply,
result={"Open_vSwitch":{"214ea68a-3cf4-4e8e-a319-4f0ba6205f17":{"initial":{"other_config":["map",[["dpdk-extra","-n
4"],["dpdk-init","true"],["dpdk-lcore-mask","0x2"],["dpdk-socket-mem","1024,1024"]]],
id=2
2016-07-31T13:15:57Z|00018|dpdk|INFO|DPDK Enabled, initializing
2016-07-31T13:15:57Z|00019|dpdk|INFO|No vhost-sock-dir provided -
defaulting to /var/run/openvswitch

2016-07-31T13:15:57Z|00020|dpdk|INFO|EAL ARGS: ovs-vswitchd -c 0x2
--socket-mem 1024,1024 -n 4

EAL: Detected lcore 47 as core 13 on socket 1
EAL: Support maximum 128 logical core(s) by configuration.
EAL: Detected 48 lcore(s)
EAL: Probing VFIO support...
EAL: Module /sys/module/vfio_pci not found! error 2 (No such file or
directory)
EAL: VFIO modules not loaded, skipping VFIO support...
EAL: Setting up physically contiguous memory...
EAL: Ask a virtual area of 0x2 bytes
EAL: Virtual area found at 0x7f50 (size = 0x2)
EAL: Ask a virtual area of 0x2 bytes
EAL: Virtual area found at 0x7f4dc000 (size = 0x2)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7f52bca0 (size = 0x20)
EAL: Ask a virtual area of 0x20 bytes
EAL: Virtual area found at 0x7f52bc60 (size = 0x20)
EAL: Ask a virtual area of 0x880 bytes
EAL: Virtual area found at 0x7f52b3c0 (size = 0x880)
EAL: Ask a virtual area of 0x20 bytes
EAL

Re: [ovs-discuss] [ovs-dev] OVS+DPDK: pci_map_resource(): cannot mmap error

[Kapil Adhikesavalu]

Hi Bhanu,

Great! Thanks for the help. Yesterday i redid the same with older kernel
and it worked. Now it makes sense.

Thanks
Kapil.

On Mon, Aug 1, 2016 at 1:54 PM, Bodireddy, Bhanuprakash <
bhanuprakash.bodire...@intel.com> wrote:

> >-Original Message-
> >From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Kapil
> >Adhikesavalu
> >Sent: Sunday, July 31, 2016 1:30 PM
> >To: d...@openvswitch.org; discuss@openvswitch.org
> >Subject: [ovs-dev] OVS+DPDK: pci_map_resource(): cannot mmap error
> >
> >Hello,
> >
> >i am getting "EAL: pci_map_resource(): cannot mmap(18, 0x7f504000,
> >0x8, 0x0): Invalid argument (0x)" when i start
> ovs-vswitchd.
> >
> >Setup:DL360gen8 CPU:E5-2967 NIC:82599ES 10-Gigabit SFI/SFP+ (2 Port) (PCI:
> >slot0: 04:00.0 04:00.1)
> >Kernel: 4.6.4-201.fc23.x86_64 ixgbe driver: 4.2.1-k
>
> There seems to be issue with 4.5+ kernel as reported at
> http://dpdk.org/ml/archives/dev/2016-July/043122.html
> commenting out "pci_request_regions(dev, "igb_uio");" in igb_uio.c should
> resolve your issue.
>
> Regards,
> Bhanu Prakash.
>
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

[ovs-discuss] Minimum number of processor cores needed to run OVS+DPDK in a kvm - HOST OS + VM environment

[Kapil Adhikesavalu]

Hello,

What will be minimum number of processor cores needed to run OVS+DPDK in a
kvm - HOST OS + VM environment?

core 1: Host OS
core 2: VM
core 3: PMD - for NIC dpdk + vhost ports - default it picks 1 core i
believe.
core 4: DPDK lcore - dpdk-lcore-mask

i have only a 4 core CPU, so i am just looking if i can run 2 VM's instead
of 1 as in above.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] Minimum number of processor cores needed to run OVS+DPDK in a kvm - HOST OS + VM environment

[Kapil Adhikesavalu]

Hi Bhanu Prakash,

Thanks for the info. Will there be any performance benefit in allocating a
core for dpdk control threads using dpdk-lcore-mask ? when i have more
cores.

Regards,
kapil.



On Mon, Aug 1, 2016 at 10:28 PM, Bodireddy, Bhanuprakash <
bhanuprakash.bodire...@intel.com> wrote:

> >-Original Message-
> >From: discuss [mailto:discuss-boun...@openvswitch.org] On Behalf Of Kapil
> >Adhikesavalu
> >Sent: Monday, August 1, 2016 5:13 PM
> >To: discuss@openvswitch.org
> >Subject: [ovs-discuss] Minimum number of processor cores needed to run
> >OVS+DPDK in a kvm - HOST OS + VM environment
> >
> >Hello,
> >
> >What will be minimum number of processor cores needed to run OVS+DPDK
> >in a kvm - HOST OS + VM environment?
> >
> >core 1: Host OS
> >core 2: VM
> >core 3: PMD - for NIC dpdk + vhost ports - default it picks 1 core i
> believe.
> Yes, If pmd-cpu-mask not specified, the pmd thread defaults to core 0.
> In case you want to explicitly pin pmd thread to core 3, pass
> pmd-cpu-mask=4. For more information check ovs-vswitchd.conf.db man pages.
>
> >core 4: DPDK lcore - dpdk-lcore-mask
> You don't have to explicitly pin dpdk control threads in this case.
>
> >
> >i have only a 4 core CPU, so i am just looking if i can run 2 VM's
> instead of 1 as
> >in above.
> You should be able to run 2 VMs on 4 core CPU.
> For better performance (core 0 - platform logic/ core 1 - VM1 qemu thread/
> core 2 - VM2 qemu thread/ core 3 - pmd thread).
>
> Regards,
> Bhanu Prakash.
>
>
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

[ovs-discuss] Append output port to an existing flow

[Kapil Adhikesavalu]

Hi,


Want to check if there is an alternate way to append a output port to the
existing flow.



For example,



Existing flow:

cookie=0x0, duration=14279.412s, table=0, n_packets=0, n_bytes=0,
idle_age=14316, dl_vlan=5 actions=output:2



If I want to add output:4 to the above flow, the only way I know is using
mod-flow



ovs-ofctl mod-flow bridge "dl_vlan=5, actions=output:2,4"



But is there any other way that I can use to just append 4? i might have
about 20 ports which have to be dynamically appended.



Why I need this?

I am testing VXLAN tunnels. They can be created/teared down dynamically.
Each VXLAN can have same or different VLAN.

Packets destined to a particular VLAN should be sent to all tunnels with
that vlan. Since tunnel learning is dynamic, using mod-flows is little bit
tricky.



Any alternate solution for this?



Regards

Kapil.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] Append output port to an existing flow

[Kapil Adhikesavalu]

Hi Ben,

I did a brief trial with 'groups' before mailing the list. Wanted to check
if there are other alternatives specific to vxlan.

Thanks for confirming. Will there be any overhead in using 1 group for each
tunnel in a scaled environment.

Regards
Kapil

Thanks
Kapil

On 08-Aug-2016 9:54 PM, "Ben Pfaff"  wrote:

On Mon, Aug 08, 2016 at 04:49:49PM +0530, Kapil Adhikesavalu wrote:
> Want to check if there is an alternate way to append a output port to the
> existing flow.
>
>
>
> For example,
>
>
>
> Existing flow:
>
> cookie=0x0, duration=14279.412s, table=0, n_packets=0, n_bytes=0,
> idle_age=14316, dl_vlan=5 actions=output:2
>
>
>
> If I want to add output:4 to the above flow, the only way I know is using
> mod-flow
>
>
>
> ovs-ofctl mod-flow bridge "dl_vlan=5, actions=output:2,4"
>
>
>
> But is there any other way that I can use to just append 4? i might have
> about 20 ports which have to be dynamically appended.

You could use the OF1.1+ "groups" feature.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

[ovs-discuss] OVS DPDK VFIO error

[Kapil Adhikesavalu]

Hi,

On a Intel xeon E5-2697 chip with iommu turned on with Intel NIC 82599, i
am getting the following error while doing the NIC binding using VFIO.
kernel: 4.23 fedora 23, i haven't tried the latest kernel yet.

E5-2697 supports IOMMU VT-d, does

VFIO NIC binding steps,

modprobe vfio-pci
sudo /usr/bin/chmod a+x /dev/vfio
sudo /usr/bin/chmod 0666 /dev/vfio/*
$DPDK_DIR/tools/dpdk_nic_bind.py --bind=vfio-pci :04:00.0
$DPDK_DIR/tools/dpdk_nic_bind.py --status

Error
=

EAL: Detected 48 lcore(s)

EAL: Probing VFIO support...

EAL:   IOMMU type 1 (Type 1) is supported

EAL:   IOMMU type 8 (No-IOMMU) is not supported

EAL: VFIO support initialized


EAL: Master lcore 1 is ready (tid=83504bc0;cpuset=[1])

EAL: PCI device :04:00.0 on NUMA socket 0

EAL:   probe driver: 8086:154d rte_ixgbe_pmd

EAL:   set IOMMU type 1 (Type 1) failed, error 1 (Operation not permitted)

EAL:   set IOMMU type 8 (No-IOMMU) failed, error 19 (No such device)

EAL:   :04:00.0 failed to select IOMMU type

EAL: Error - exiting with code: 1

  Cause: Requested device :04:00.0 cannot be used


dmesg:
==

[0.997461] DMAR: Ignoring identity map for HW passthrough device
:00:1f.0 [0x0 - 0xff]

[0.997465] DMAR: Intel(R) Virtualization Technology for Directed I/O

[1.351801] DMAR: 32bit :00:1a.0 uses non-identity mapping

[1.362623] DMAR: 32bit :00:1d.0 uses non-identity mapping

[1.373601] DMAR: 32bit :01:00.4 uses non-identity mapping

[  297.035504] vfio-pci :04:00.0: Device is ineligible for IOMMU domain
attach due to platform RMRR requirement.  Contact your platform vendor.



[root@localhost bin]# cat /proc/cmdline

BOOT_IMAGE=/vmlinuz-4.2.3-300.fc23.x86_64 root=/dev/mapper/fedora-root ro
rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap rhgb quiet
default_hugepagesz=1G hugepagesz=1G hugepages=16 hugepagesz=2M
hugepages=2048 iommu=pt intel_iommu=on


demsg | grep 10G  - 82599 controller

04:00.0 Ethernet controller: Intel Corporation Ethernet 10G 2P X520 Adapter
(rev 01)

04:00.1 Ethernet controller: Intel Corporation Ethernet 10G 2P X520 Adapter
(rev 01)

Regards
Kapil.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] OVS DPDK VFIO error

[Kapil Adhikesavalu]

:00:1f.0 [0x0 - 0xff]
[0.997465] DMAR: Intel(R) Virtualization Technology for Directed I/O
[1.351801] DMAR: 32bit :00:1a.0 uses non-identity mapping
[1.362623] DMAR: 32bit :00:1d.0 uses non-identity mapping
[1.373601] DMAR: 32bit :01:00.4 uses non-identity mapping
[  297.035504] vfio-pci :04:00.0: Device is ineligible for IOMMU domain
attach due to platform RMRR requirement.  Contact your platform vendor.

Regards
kapil.

On Tue, Aug 9, 2016 at 5:38 PM, Bodireddy, Bhanuprakash <
bhanuprakash.bodire...@intel.com> wrote:

> >-Original Message-
> >From: discuss [mailto:discuss-boun...@openvswitch.org] On Behalf Of Kapil
> >Adhikesavalu
> >Sent: Tuesday, August 9, 2016 10:46 AM
> >To: d...@openvswitch.org; discuss@openvswitch.org
> >Subject: [ovs-discuss] OVS DPDK VFIO error
> >
> >Hi,
> >
> >On a Intel xeon E5-2697 chip with iommu turned on with Intel NIC 82599, i
> am
> >getting the following error while doing the NIC binding using VFIO.
> >kernel: 4.23 fedora 23, i haven't tried the latest kernel yet.
> >
> >E5-2697 supports IOMMU VT-d
> I hope you have already enabled VT-d in BIOS, can you check 'dmesg | grep
> -e DMAR -e IOMMU'.
>
> >
> >VFIO NIC binding steps,
> >modprobe vfio-pci
> >sudo /usr/bin/chmod a+x /dev/vfio
> >sudo /usr/bin/chmod 0666 /dev/vfio/*
> >$DPDK_DIR/tools/dpdk_nic_bind.py --bind=vfio-pci :04:00.0
> >$DPDK_DIR/tools/dpdk_nic_bind.py --status
> >Error
> >=
> >EAL: Detected 48 lcore(s)
> >EAL: Probing VFIO support...
> >EAL:   IOMMU type 1 (Type 1) is supported
> >EAL:   IOMMU type 8 (No-IOMMU) is not supported
> >EAL: VFIO support initialized
> >
> >EAL: Master lcore 1 is ready (tid=83504bc0;cpuset=[1])
> >EAL: PCI device :04:00.0 on NUMA socket 0
> >EAL:   probe driver: 8086:154d rte_ixgbe_pmd
> >EAL:   set IOMMU type 1 (Type 1) failed, error 1 (Operation not permitted)
> >EAL:   set IOMMU type 8 (No-IOMMU) failed, error 19 (No such device)
> >EAL:   :04:00.0 failed to select IOMMU type
> >EAL: Error - exiting with code: 1
> >  Cause: Requested device :04:00.0 cannot be used
> >
> >dmesg:
> >==
> >[0.997461] DMAR: Ignoring identity map for HW passthrough device
> >:00:1f.0 [0x0 - 0xff]
> >[0.997465] DMAR: Intel(R) Virtualization Technology for Directed I/O
> >[1.351801] DMAR: 32bit :00:1a.0 uses non-identity mapping
> >[1.362623] DMAR: 32bit :00:1d.0 uses non-identity mapping
> >[1.373601] DMAR: 32bit :01:00.4 uses non-identity mapping
> >[  297.035504] vfio-pci :04:00.0: Device is ineligible for IOMMU
> domain
> >attach due to platform RMRR requirement.  Contact your platform vendor.
> >
> >
> >[root@localhost bin]# cat /proc/cmdline
> >BOOT_IMAGE=/vmlinuz-4.2.3-300.fc23.x86_64 root=/dev/mapper/fedora-
> >root ro rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap rhgb quiet
> >default_hugepagesz=1G hugepagesz=1G hugepages=16 hugepagesz=2M
> >hugepages=2048 iommu=pt intel_iommu=on
>
> I don’t see any problem with your cmdline as  iommu=pt and intel_iommu is
> added.
>
> Regards,
> Bhanu Prakash.
>
> >
> >demsg | grep 10G  - 82599 controller
> >04:00.0 Ethernet controller: Intel Corporation Ethernet 10G 2P X520
> Adapter
> >(rev 01)
> >04:00.1 Ethernet controller: Intel Corporation Ethernet 10G 2P X520
> Adapter
> >(rev 01)
> >
> >Regards
> >Kapil.
>
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] Minimum number of processor cores needed to run OVS+DPDK in a kvm - HOST OS + VM environment

[Kapil Adhikesavalu]

Hi Bhanu Prakash,

With the below configuration, i am running IPSEC on the VM, which is not
scaling more than 400M unidirectional traffic per VM with Intel
Atom C2518@1.7Ghz.

ksoftirqd/0 process in the VM is shooting up to 95% for 400M, and it is not
able to handle any more traffic. Is there anything i can do to get better
performance with the quad core Atom CPU. Will assigning multiple queues in
the qemu/vhost/vm help ?

"For better performance (core 0 - platform logic/ core 1 - VM1 qemu thread/
core 2 - VM2 qemu thread/ core 3 - pmd thread)."

Regards
Kapil.

On Mon, Aug 1, 2016 at 10:45 PM, Kapil Adhikesavalu 
wrote:

> Hi Bhanu Prakash,
>
> Thanks for the info. Will there be any performance benefit in allocating a
> core for dpdk control threads using dpdk-lcore-mask ? when i have more
> cores.
>
> Regards,
> kapil.
>
>
>
> On Mon, Aug 1, 2016 at 10:28 PM, Bodireddy, Bhanuprakash <
> bhanuprakash.bodire...@intel.com> wrote:
>
>> >-Original Message-
>> >From: discuss [mailto:discuss-boun...@openvswitch.org] On Behalf Of
>> Kapil
>> >Adhikesavalu
>> >Sent: Monday, August 1, 2016 5:13 PM
>> >To: discuss@openvswitch.org
>> >Subject: [ovs-discuss] Minimum number of processor cores needed to run
>> >OVS+DPDK in a kvm - HOST OS + VM environment
>> >
>> >Hello,
>> >
>> >What will be minimum number of processor cores needed to run OVS+DPDK
>> >in a kvm - HOST OS + VM environment?
>> >
>> >core 1: Host OS
>> >core 2: VM
>> >core 3: PMD - for NIC dpdk + vhost ports - default it picks 1 core i
>> believe.
>> Yes, If pmd-cpu-mask not specified, the pmd thread defaults to core 0.
>> In case you want to explicitly pin pmd thread to core 3, pass
>> pmd-cpu-mask=4. For more information check ovs-vswitchd.conf.db man pages.
>>
>> >core 4: DPDK lcore - dpdk-lcore-mask
>> You don't have to explicitly pin dpdk control threads in this case.
>>
>> >
>> >i have only a 4 core CPU, so i am just looking if i can run 2 VM's
>> instead of 1 as
>> >in above.
>> You should be able to run 2 VMs on 4 core CPU.
>> For better performance (core 0 - platform logic/ core 1 - VM1 qemu
>> thread/ core 2 - VM2 qemu thread/ core 3 - pmd thread).
>>
>> Regards,
>> Bhanu Prakash.
>>
>>
>
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] Minimum number of processor cores needed to run OVS+DPDK in a kvm - HOST OS + VM environment

[Kapil Adhikesavalu]

Hi Bhanu Prakash.

I am already using the AES-NI in the VM, without that its performs worse.
Processor also supports Intel QAT for crypto, will look at that.

Regards,
Kapil.

On Wed, Aug 10, 2016 at 3:39 PM, Bodireddy, Bhanuprakash <
bhanuprakash.bodire...@intel.com> wrote:

>
> >-Original Message-
> >From: Kapil Adhikesavalu [mailto:kapil20...@gmail.com]
> >Sent: Wednesday, August 10, 2016 10:25 AM
> >To: Bodireddy, Bhanuprakash 
> >Cc: discuss@openvswitch.org
> >Subject: Re: [ovs-discuss] Minimum number of processor cores needed to run
> >OVS+DPDK in a kvm - HOST OS + VM environment
> >
> >Hi Bhanu Prakash,
> >
> >With the below configuration, i am running IPSEC on the VM, which is not
> >scaling more than 400M unidirectional traffic per VM with Intel
> >Atom C2518@1.7Ghz.
> When running IPSEC, most cycles are spent on encryption/decryption.  One
> thing to check is
> If the processor supports AES-NI instructions and to leverage them to
> improve performance.
>
> >
> >ksoftirqd/0 process in the VM is shooting up to 95% for 400M, and it is
> not able
> >to handle any more traffic. Is there anything i can do to get better
> >performance with the quad core Atom CPU. Will assigning multiple queues in
> >the qemu/vhost/vm help ?
> In OVS, there is multiqueue and also manual pinning of rxqs support where
> in you can explicitly pin a queue
> to a core. But given that you have few cores(4) it may not help In your
> case.
>
> Regards,
> Bhanu Prakash.
>
> >
> >"For better performance (core 0 - platform logic/ core 1 - VM1 qemu
> thread/
> >core 2 - VM2 qemu thread/ core 3 - pmd thread)."
> >
> >Regards
> >Kapil.
> >
> >On Mon, Aug 1, 2016 at 10:45 PM, Kapil Adhikesavalu
> > wrote:
> >Hi Bhanu Prakash,
> >
> >Thanks for the info. Will there be any performance benefit in allocating
> a core
> >for dpdk control threads using dpdk-lcore-mask ? when i have more cores.
> >
> >Regards,
> >kapil.
> >
> >
> >
> >On Mon, Aug 1, 2016 at 10:28 PM, Bodireddy, Bhanuprakash
> > wrote:
> >>-Original Message-
> >>From: discuss [mailto:discuss-boun...@openvswitch.org] On Behalf Of
> Kapil
> >>Adhikesavalu
> >>Sent: Monday, August 1, 2016 5:13 PM
> >>To: discuss@openvswitch.org
> >>Subject: [ovs-discuss] Minimum number of processor cores needed to run
> >>OVS+DPDK in a kvm - HOST OS + VM environment
> >>
> >>Hello,
> >>
> >>What will be minimum number of processor cores needed to run OVS+DPDK
> >>in a kvm - HOST OS + VM environment?
> >>
> >>core 1: Host OS
> >>core 2: VM
> >>core 3: PMD - for NIC dpdk + vhost ports - default it picks 1 core i
> believe.
> >Yes, If pmd-cpu-mask not specified, the pmd thread defaults to core 0.
> >In case you want to explicitly pin pmd thread to core 3, pass
> pmd-cpu-mask=4.
> >For more information check ovs-vswitchd.conf.db man pages.
> >
> >>core 4: DPDK lcore - dpdk-lcore-mask
> >You don't have to explicitly pin dpdk control threads in this case.
> >
> >>
> >>i have only a 4 core CPU, so i am just looking if i can run 2 VM's
> instead of 1 as
> >>in above.
> >You should be able to run 2 VMs on 4 core CPU.
> >For better performance (core 0 - platform logic/ core 1 - VM1 qemu thread/
> >core 2 - VM2 qemu thread/ core 3 - pmd thread).
> >
> >Regards,
> >Bhanu Prakash.
> >
>
>
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

[ovs-discuss] Queue priority

[Kapil Adhikesavalu]

Hi,

Can OVS supports priority queues.Meaning, any packet comes with .1p high
priority send to High priority Queues. I couldn't find this info from the
available docs.
The requirement was to send all network control packets to high priority
queue.Even if Data traffic comes with high rate, the network control packets
should never be dropped.

Regards

Kapil.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] Queue priority

[Kapil Adhikesavalu]

Thanks Ben

using flow rules i can send it to the desired queues.
currently i see only 2 types of Qos was supported : linux-htb and
linux-hfsc.
if i use linux-htb, what it actually gives me was bandwidth shared priority
queue.

lets take an example

i will create 2 queues.
q1 i will use for arp and icmp packets
q2 i will use for data packets
if max rate of port was 1gig.

lets say both can have max rate of 1 gig each

how to make sure that Control packets in q1 are processed first before
processing data packets in q2. so that packets may not get dropped in Q1.

I did not see much info about this in OVS,not in linux-htb docs. linux-htb
docs says more on rate-limiting
but my requirement is during congestion, Control packet software queues
should empty first before data packet queues

Appreciate you valuable answers

Regards
kapil.

On Fri, Aug 19, 2016 at 7:31 PM, Ben Pfaff  wrote:

> On Fri, Aug 19, 2016 at 07:00:23AM -0700, Ben Pfaff wrote:
> > On Fri, Aug 19, 2016 at 06:53:31PM +0530, Kapil Adhikesavalu wrote:
> > > Can OVS supports priority queues.Meaning, any packet comes with .1p
> high
> > > priority send to High priority Queues. I couldn't find this info from
> the
> > > available docs.
> > > The requirement was to send all network control packets to high
> priority
> > > queue.Even if Data traffic comes with high rate, the network control
> packets
> > > should never be dropped.
> >
> > You can use flows to set any DSCP you like.
>
> Or 802.1p priority as I guess that's what you're concerned with in this
> case.
>
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

[ovs-discuss] Multiqueue with dpdk ports

[Kapil Adhikesavalu]

Hello,

OVS + DPDK provides a way to configure multiqueue for dpdk ports (in turn
vhost user ports as well).

 ovs-vsctl set Open_vSwitch . other_config:pmd-cpu-mask=c
 ovs-vsctl set Interface dpdk0 options:n_rxq=2
 ovs-vsctl set Interface dpdk1 options:n_rxq=2

Based on what parameter, the packets received on dpdk port will be split
across these queues. Something like MAC/IP ? is it static or configurable.?

I am looking to find whether the Rx queues can be configured to receive a
specific type of packets alone? control, data packets having separate
queues.

Regards
Kapil.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

[ovs-discuss] VHost QOS - per queue rate limiting

[Kapil Adhikesavalu]

Hello,

Is VHost port - per queue rate limiting feature expected in near future ?

Currently its on port basis, and if we assign more than 1 queue to the
vHost port, it will be good to do QOS on per queue.

https://github.com/openvswitch/ovs/blob/master/INSTALL.DPDK-ADVANCED.md


7. QOS

Here is an example on QOS usage. Assuming you have a vhost-user port
transmitting traffic consisting of packets of size 64 bytes, the following
command would limit the egress transmission rate of the port to ~1,000,000
packets per second

ovs-vsctl set port vhost-user0 qos=@newqos -- --id=@newqos create qos
type=egress-policer other-config:cir=4600 other-config:cbs=2048

To examine the QoS configuration of the port:

ovs-appctl -t ovs-vswitchd qos/show vhost-user0

To clear the QoS configuration from the port and ovsdb use the following:

ovs-vsctl destroy QoS vhost-user0 -- clear Port vhost-user0 qos

Regards

Kapil
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

[ovs-discuss] Configuring MTU for dpdk and vhost ports

[Kapil Adhikesavalu]

Hi,

Is there a way to configure MTU for dpdk and vhost ports from its default
1500 ?
I read, "with OVS, Normally the MTU should be changed using operating
system specific interfaces (e.g. ifconfig).", but as they are dpdk ports,
how can i configure them ?

Regards
Kapil
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] Configuring MTU for dpdk and vhost ports

[Kapil Adhikesavalu]

Thanks Mark, just figured that myself, i wasn't using the latest OVS, so
mtu_request wasn't working.. Appreciate your help.

Regards
Kapil.

On Tue, Sep 27, 2016 at 8:47 PM, Kavanagh, Mark B  wrote:

> >
> >Hi,
> >
> >Is there a way to configure MTU for dpdk and vhost ports from its default
> 1500 ?
> >I read, "with OVS, Normally the MTU should be changed using operating
> system specific
> >interfaces (e.g. ifconfig).", but as they are dpdk ports, how can i
> configure them ?
> >
>
> Hi Kapil,
>
> Depending on the version of OvS that you're using, you may use the
> Interface's 'mtu_request' field to modify the MTU of DPDK-type ports.
>
> From INSTALL.DPDK-ADVANCED.md:
>
> "By default, DPDK ports are configured with standard Ethernet MTU
> (1500B). To
> enable Jumbo Frames support for a DPDK port, change the
> Interface's `mtu_request`
> attribute to a sufficiently large value.
>
> e.g. Add a DPDK Phy port with MTU of 9000:
>
> `ovs-vsctl add-port br0 dpdk0 -- set Interface dpdk0 type=dpdk --
> set Interface dpdk0 mtu_request=9000`
>
> e.g. Change the MTU of an existing port to 6200:
>
> `ovs-vsctl set Interface dpdk0 mtu_request=6200`"
>
> This functionality is currently supported on OvS Master and 2.6 branches.
>
> Hope this helps,
> Mark
>
> >Regards
> >Kapil
>
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

[ovs-discuss] Hugepages allocation

[Kapil Adhikesavalu]

Hi,

1. in INSTALL.DPDK.md, huge page size is recommended as 2MB pages. Earlier
i remember seeing some reference to use 1GB huge pages. is there any
noticeable performance improvement in using 1G hugepages vs 2M pages ?
2. is there a way to allocate 1G hugepages using sysctl. Default hugepage
size is 2M and i didn't find any way to modify it using sysctl. is grub
config the only way to allocate 1GB pages ?
3. Is there any difference in allocating huge pages run time vs
persistent(/etc/sysctl.d/hugepages.conf) ? will the hugepages allocated at
runtime will be fragmented or something?

Regards
Kapil.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] [ovs-dev] Hugepages allocation

[Kapil Adhikesavalu]

Hi Bhanuprakash,

Thanks for the info. Helpful!

Regards
Kapil.

On Mon, Oct 3, 2016 at 5:41 PM, Bodireddy, Bhanuprakash <
bhanuprakash.bodire...@intel.com> wrote:

>
> >-Original Message-
> >From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Kapil
> >Adhikesavalu
> >Sent: Monday, October 3, 2016 12:07 PM
> >To: d...@openvswitch.org; discuss@openvswitch.org
> >Subject: [ovs-dev] Hugepages allocation
> >
> >Hi,
> >
> >1. in INSTALL.DPDK.md, huge page size is recommended as 2MB pages.
> Earlier
> >i remember seeing some reference to use 1GB huge pages. is there any
> >noticeable performance improvement in using 1G hugepages vs 2M pages ?
>
> We did some benchmarks and found that there isn't any significant
> performance difference using 2MB hugepages over 1GB pages.
>
> >2. is there a way to allocate 1G hugepages using sysctl. Default hugepage
> size
> >is 2M and i didn't find any way to modify it using sysctl. is grub config
> the only
> >way to allocate 1GB pages ?
>
> Yes, for this one has to build kernel with CONFIG_CMA. In case the kernel
> is built with this, one can allocate hugepages at run time as below
> echo N > /sys/devices/system/node/nodeX/hugepages/hugepages-
> 1048576kB/nr_hugepages
>
> >3. Is there any difference in allocating huge pages run time vs
> >persistent(/etc/sysctl.d/hugepages.conf) ? will the hugepages allocated
> at
> >runtime will be fragmented or something?
> The only advantage of allocating hugepages at boot time is you are sure to
> get the requested pages as the memory isn't fragmented.
> if memory is too fragmented the chances are that  fewer pages would be
> allocated by kernel than requested.
>
> >
> >Regards
> >Kapil.
> >___
> >dev mailing list
> >d...@openvswitch.org
> >http://openvswitch.org/mailman/listinfo/dev
>
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

[ovs-discuss] packets getting dropped in vhostuser port

[Kapil Adhikesavalu]

Hi,

In a PHY-VM-PHY setup, i was using dpdk16.04 + OVS 2.5.90 + qemu 2.4.1,
everything was working fine.
When i upgraded to dpdk 16.07 + ovs 2.6 (branch-2.6) without any change to
the setup/configuration; now all the packets(1200B) are getting dropped at
vhostuser ports. Though, i am able to send traffic from dpdk PHY to PHY
with the same setup,

Is there any qemu version dependency here ? some input on how to debug this
will help.
One thing that looks a bit odd is ovs-vswitchd start logs, i dont see PCI
memory map in the logs(mentioned at the end).
Let me know if any other logs are required.

[root@localhost ~]# ovs-vsctl show
e622d6bc-ea72-4232-a035-e1aa75c5887a
Bridge "br-dpdk0"
Port "dpdk0"
Interface "dpdk0"
type: dpdk
Port "vhost-1-0"
Interface "vhost-1-0"
type: dpdkvhostuser
Port "br-dpdk0"
Interface "br-dpdk0"
type: internal
Bridge "br-dpdk1"
Port "br-dpdk1"
Interface "br-dpdk1"
type: internal
Port "vhost-1-1"
Interface "vhost-1-1"
type: dpdkvhostuser
Port "dpdk1"
Interface "dpdk1"
type: dpdk

[root@localhost ~]# ovs-vsctl -Version
ovs-vsctl (Open vSwitch) 2.6.1
DB Schema 7.14.0

/usr/bin/qemu-system-x86_64 -machine accel=kvm -name ona-vm-1 -S -machine
pc-i440fx-2.4,accel=kvm,usb=off -m 1024 -realtime mlock=off -smp
1,sockets=2,cores=1,threads=1 -uuid d6055bcd-ce40-49a7-a3b9-4852b15fbeb1
-nographic -no-user-config -nodefaults -chardev
socket,id=charmonitor,path=/var/lib/libvirt/qemu/ona-vm-1.monitor,server,nowait
-mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown
-boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive
file=/var/lib/bristol/vm-1/1.img,if=none,id=drive-ide0-0-0,format=raw,cache=none
-device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -drive
file=/root/genericx86-64.iso,if=none,id=drive-ide0-1-0,readonly=on,format=raw
-device
ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=1
-netdev tap,fd=24,id=hostnet0 -device
e1000,netdev=hostnet0,id=net0,mac=52:54:00:ee:9f:c7,bus=pci.0,addr=0x2
-chardev pty,id=charserial0 -device
isa-serial,chardev=charserial0,id=serial0 -chardev
socket,id=char0,path=/var/run/openvswitch/vhost-1-0 -chardev
socket,id=char1,path=/var/run/openvswitch/vhost-1-1 -msg timestamp=on -cpu
Haswell,+pdpe1gb -rtc base=utc -numa node,memdev=mem -nographic
-mem-prealloc -enable-kvm -m 1024 -realtime mlock=off -device
virtio-net-pci,addr=0x04,netdev=net0,mac=92:10:9b:00:01:00,csum=off,gso=off,guest_tso4=off,guest_tso6=off,guest_ecn=off,mrg_rxbuf=off
-device
virtio-net-pci,addr=0x05,netdev=net1,mac=92:10:9b:00:01:01,csum=off,gso=off,guest_tso4=off,guest_tso6=off,guest_ecn=off,mrg_rxbuf=off
-object
memory-backend-file,id=mem,size=1024M,mem-path=/dev/hugepages,share=on
-netdev type=vhost-user,id=net0,chardev=char0,vhostforce -netdev
type=vhost-user,id=net1,chardev=char1,vhostforce -msg timestamp=on

[root@localhost ~]# ovs-appctl dpctl/show
netdev@ovs-netdev:
lookups: hit:1661391 missed:38 lost:0
flows: 7
port 0: ovs-netdev (tap)
port 1: br-dpdk0 (tap)
port 2: br-dpdk1 (tap)
port 3: dpdk0 (dpdk: configured_rx_queues=1,
configured_tx_queues=5, mtu=1500, requested_rx_queues=1,
requested_tx_queues=5)
port 4: dpdk1 (dpdk: configured_rx_queues=1,
configured_tx_queues=5, mtu=1500, requested_rx_queues=1,
requested_tx_queues=5)
port 5: vhost-1-0 (dpdkvhostuser: configured_rx_queues=1,
configured_tx_queues=1, mtu=1500, requested_rx_queues=1,
requested_tx_queues=1)
port 6: vhost-1-1 (dpdkvhostuser: configured_rx_queues=1,
configured_tx_queues=1, mtu=1500, requested_rx_queues=1,
requested_tx_queues=1)

[root@localhost ~]# ovs-appctl dpif-netdev/pmd-rxq-show
pmd thread numa_id 0 core_id 1:
isolated : false
port: vhost-1-1 queue-id: 0
port: dpdk1 queue-id: 0
port: vhost-1-0 queue-id: 0
port: dpdk0 queue-id: 0

Drops: (traffic sent from br-dpdk1's port1 to port 2 to vm)
=
[root@localhost ~]# ovs-ofctl dump-ports br-dpdk1
OFPST_PORT reply (xid=0x2): 3 ports
  port LOCAL: rx pkts=14, bytes=1156, drop=0, errs=0, frame=0, over=0, crc=0
   tx pkts=181918, bytes=108422056, drop=0, errs=0, coll=0
  port  1: rx pkts=181927, bytes=108422763, drop=0, errs=0, frame=?,
over=?, crc=?
   tx pkts=8, bytes=648, drop=0, errs=0, coll=?
  port  2: rx pkts=?, bytes=0, drop=0, errs=0, frame=?, over=?, crc=?
   tx pkts=?, bytes=0, drop=181923, errs=?, coll=?


[root@localhost ~]# ovs-ofctl dump-ports br-dpdk0
OFPST_PORT reply (xid=0x2): 3 ports
  port LOCAL: rx pkts=13, bytes=1066, drop=0, errs=0, frame=0, over=0, crc=0
   tx pkts=19, bytes=2296, drop=0, errs=0, coll=0
  port  1: rx pkts=22, bytes=3010, drop=0, errs=0, frame=?, over=?, crc=?
   tx pkts=23, byte

Re: [ovs-discuss] [ovs-dev] packets getting dropped in vhostuser port

[Kapil Adhikesavalu]

There seem to be some version dependency between the two.
dpdk-16.04 with ovs2.6 is not possible as ovs is referencing some newer
dpdk code.

i tried the reverse, dpdk16.07 and ovs2.5.9, but getting the following
error (rpm based build)

+ cd dpdk
+ make config T=x86_64-atm-linuxapp-gcc
make[1]: *** No rule to make target
'/tmp/kapil/rpm-build/openvswitch-2.5.90/dpdk/config/defconfig_x86_64-atm-linuxapp-gcc',
needed by '/tmp/kapil/rpm-build/openvswitch-2.5.90/dpdk/build/.config'.
Stop.
/tmp/kapil/rpm-build/openvswitch-2.5.90/dpdk/mk/rte.sdkroot.mk:90: recipe
for target 'config' failed

its building fine with 16.04, only if replace with 16.07, getting this
error.


On Wed, Oct 19, 2016 at 7:24 PM, Xu, Qian Q  wrote:

> One suggestion, could you keep dpdk as dpdk-16.04, only ovs upgrade, then
> see if the case still happen. Or you can keep only dpdk changed but no OVS
> change. We need to narrow down the issue. From my knowledge, qemu-2.4.1 is
> fine for the case.
>
> -Original Message-
> From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Kapil
> Adhikesavalu
> Sent: Wednesday, October 19, 2016 2:18 PM
> To: d...@openvswitch.org; discuss@openvswitch.org
> Subject: [ovs-dev] packets getting dropped in vhostuser port
>
> Hi,
>
> In a PHY-VM-PHY setup, i was using dpdk16.04 + OVS 2.5.90 + qemu 2.4.1,
> everything was working fine.
> When i upgraded to dpdk 16.07 + ovs 2.6 (branch-2.6) without any change to
> the setup/configuration; now all the packets(1200B) are getting dropped at
> vhostuser ports. Though, i am able to send traffic from dpdk PHY to PHY
> with the same setup,
>
> Is there any qemu version dependency here ? some input on how to debug
> this will help.
> One thing that looks a bit odd is ovs-vswitchd start logs, i dont see PCI
> memory map in the logs(mentioned at the end).
> Let me know if any other logs are required.
>
> [root@localhost ~]# ovs-vsctl show
> e622d6bc-ea72-4232-a035-e1aa75c5887a
> Bridge "br-dpdk0"
> Port "dpdk0"
> Interface "dpdk0"
> type: dpdk
> Port "vhost-1-0"
> Interface "vhost-1-0"
> type: dpdkvhostuser
> Port "br-dpdk0"
> Interface "br-dpdk0"
> type: internal
> Bridge "br-dpdk1"
> Port "br-dpdk1"
> Interface "br-dpdk1"
> type: internal
> Port "vhost-1-1"
> Interface "vhost-1-1"
> type: dpdkvhostuser
> Port "dpdk1"
> Interface "dpdk1"
> type: dpdk
>
> [root@localhost ~]# ovs-vsctl -Version
> ovs-vsctl (Open vSwitch) 2.6.1
> DB Schema 7.14.0
>
> /usr/bin/qemu-system-x86_64 -machine accel=kvm -name ona-vm-1 -S -machine
> pc-i440fx-2.4,accel=kvm,usb=off -m 1024 -realtime mlock=off -smp
> 1,sockets=2,cores=1,threads=1 -uuid d6055bcd-ce40-49a7-a3b9-4852b15fbeb1
> -nographic -no-user-config -nodefaults -chardev
> socket,id=charmonitor,path=/var/lib/libvirt/qemu/ona-vm-1.
> monitor,server,nowait
> -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc
> -no-shutdown -boot strict=on -device 
> piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2
> -drive file=/var/lib/bristol/vm-1/1.img,if=none,id=drive-ide0-0-0,
> format=raw,cache=none
> -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -drive
> file=/root/genericx86-64.iso,if=none,id=drive-ide0-1-0,
> readonly=on,format=raw
> -device
> ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=1
> -netdev tap,fd=24,id=hostnet0 -device
> e1000,netdev=hostnet0,id=net0,mac=52:54:00:ee:9f:c7,bus=pci.0,addr=0x2
> -chardev pty,id=charserial0 -device
> isa-serial,chardev=charserial0,id=serial0 -chardev
> socket,id=char0,path=/var/run/openvswitch/vhost-1-0 -chardev
> socket,id=char1,path=/var/run/openvswitch/vhost-1-1 -msg timestamp=on
> -cpu Haswell,+pdpe1gb -rtc base=utc -numa node,memdev=mem -nographic
> -mem-prealloc -enable-kvm -m 1024 -realtime mlock=off -device
> virtio-net-pci,addr=0x04,netdev=net0,mac=92:10:9b:00:
> 01:00,csum=off,gso=off,guest_tso4=off,guest_tso6=off,guest_
> ecn=off,mrg_rxbuf=off
> -device
> virtio-net-pci,addr=0x05,netdev=net1,mac=92:10:9b:00:
> 01:01,csum=off,gso=off,guest_tso4=off,guest_tso6=off,guest_
> ecn=off,mrg_rxbuf=off
> -object
> memory-backend-file,id=mem,size=1024M,mem-path=/dev/hugepages,share=on
> -netdev type=vhost-user,id=net0,chardev=char0,vhostforce -netdev
> type=vhost-user,id=net1,chardev=char1,vhostforce -msg timestamp=on
>
> [root@localhost ~]# ovs-appctl dpctl/show
> netdev@ovs-netdev

Re: [ovs-discuss] [ovs-dev] packets getting dropped in vhostuser port

[Kapil Adhikesavalu]

Hi

I was moving to latest version of ovs + dpdk for jumbo frame support.
Will i be able to get jumbo frame support in ovs 2.5.9 + dpdk 16.04 ? i
dont want a way to configure mtu as in 2.6, just a hard coded jumbo frame
size should do.

i see testpmd has a way to configure mtu on dpdk(in 16.04), So while
creating the dpdk interface through ovs, will i able to modify ovs code to
pass the default mtu size as 2000 and create the dpdk port ?

Regards
Kapil

On Wed, Oct 19, 2016 at 8:30 PM, Kapil Adhikesavalu 
wrote:

> There seem to be some version dependency between the two.
> dpdk-16.04 with ovs2.6 is not possible as ovs is referencing some newer
> dpdk code.
>
> i tried the reverse, dpdk16.07 and ovs2.5.9, but getting the following
> error (rpm based build)
>
> + cd dpdk
> + make config T=x86_64-atm-linuxapp-gcc
> make[1]: *** No rule to make target '/tmp/kapil/rpm-build/
> openvswitch-2.5.90/dpdk/config/defconfig_x86_64-atm-linuxapp-gcc', needed
> by '/tmp/kapil/rpm-build/openvswitch-2.5.90/dpdk/build/.config'.  Stop.
> /tmp/kapil/rpm-build/openvswitch-2.5.90/dpdk/mk/rte.sdkroot.mk:90: recipe
> for target 'config' failed
>
> its building fine with 16.04, only if replace with 16.07, getting this
> error.
>
>
> On Wed, Oct 19, 2016 at 7:24 PM, Xu, Qian Q  wrote:
>
>> One suggestion, could you keep dpdk as dpdk-16.04, only ovs upgrade, then
>> see if the case still happen. Or you can keep only dpdk changed but no OVS
>> change. We need to narrow down the issue. From my knowledge, qemu-2.4.1 is
>> fine for the case.
>>
>> -Original Message-
>> From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Kapil
>> Adhikesavalu
>> Sent: Wednesday, October 19, 2016 2:18 PM
>> To: d...@openvswitch.org; discuss@openvswitch.org
>> Subject: [ovs-dev] packets getting dropped in vhostuser port
>>
>> Hi,
>>
>> In a PHY-VM-PHY setup, i was using dpdk16.04 + OVS 2.5.90 + qemu 2.4.1,
>> everything was working fine.
>> When i upgraded to dpdk 16.07 + ovs 2.6 (branch-2.6) without any change
>> to the setup/configuration; now all the packets(1200B) are getting dropped
>> at vhostuser ports. Though, i am able to send traffic from dpdk PHY to PHY
>> with the same setup,
>>
>> Is there any qemu version dependency here ? some input on how to debug
>> this will help.
>> One thing that looks a bit odd is ovs-vswitchd start logs, i dont see PCI
>> memory map in the logs(mentioned at the end).
>> Let me know if any other logs are required.
>>
>> [root@localhost ~]# ovs-vsctl show
>> e622d6bc-ea72-4232-a035-e1aa75c5887a
>> Bridge "br-dpdk0"
>> Port "dpdk0"
>> Interface "dpdk0"
>> type: dpdk
>> Port "vhost-1-0"
>> Interface "vhost-1-0"
>> type: dpdkvhostuser
>> Port "br-dpdk0"
>> Interface "br-dpdk0"
>> type: internal
>> Bridge "br-dpdk1"
>> Port "br-dpdk1"
>> Interface "br-dpdk1"
>> type: internal
>> Port "vhost-1-1"
>> Interface "vhost-1-1"
>> type: dpdkvhostuser
>> Port "dpdk1"
>> Interface "dpdk1"
>> type: dpdk
>>
>> [root@localhost ~]# ovs-vsctl -Version
>> ovs-vsctl (Open vSwitch) 2.6.1
>> DB Schema 7.14.0
>>
>> /usr/bin/qemu-system-x86_64 -machine accel=kvm -name ona-vm-1 -S -machine
>> pc-i440fx-2.4,accel=kvm,usb=off -m 1024 -realtime mlock=off -smp
>> 1,sockets=2,cores=1,threads=1 -uuid d6055bcd-ce40-49a7-a3b9-4852b15fbeb1
>> -nographic -no-user-config -nodefaults -chardev
>> socket,id=charmonitor,path=/var/lib/libvirt/qemu/ona-vm-1.mo
>> nitor,server,nowait
>> -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc
>> -no-shutdown -boot strict=on -device 
>> piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2
>> -drive file=/var/lib/bristol/vm-1/1.img,if=none,id=drive-ide0-0-0,f
>> ormat=raw,cache=none
>> -device ide-hd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -drive
>> file=/root/genericx86-64.iso,if=none,id=drive-ide0-1-0,reado
>> nly=on,format=raw
>> -device
>> ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=1
>> -netdev tap,fd=24,id=hostnet0 -device
>> e1000,netdev=hostnet0,id=net0,mac=52:54:00:ee:9f:c7,bus=pci.0,addr=0x2
>> -chardev pty,id=charserial0 -device
>> isa-serial,chardev=charserial0,id

[ovs-discuss] Vhostports drop issue - related to MTU - Qemu version

[Kapil Adhikesavalu]

Hi,

Issue Setup:  DPDK 16.07 + OVS 2.6.0 + qemu 2.4.1 : PHY-VM-PHY

I am trying to upgrade from (DPDK16.04 + OVS2.5.9), to (DPDK16.07 +
OVS2.6.0) for jumbo frame support. After the upgrade, all packets are
getting dropped on the vhostuser port.
The dpdk/vhost user ports used here has default MTU of 1500 and packets are
within the MTU size.

Upon few trails, i found configuring the mtu on the vhostuser port is
somehow fixing the drop issue. Command used : ovs-vsctl set interface
vhostuser1 mtu_request=1400(to any value works).
Though even with this, if i reboot the VM, again the drop issue shows up
and mtu has to be reconfigured/changed on the vhost to get the traffic
working.
Seems, modifying the mtu value on vhost is internally triggering something
which resolves the drop issue.

I upgraded the qemu to 2.6.2, which resolves the drop issue in the vhost
ports without any changes to default MTU.
I suspect, if its some interop issue with qemu 2.4.1, after the addition of
jumbo frame support in OVS 2.6.0.

Some input on how to debug this will help. is there any dependency on
dpdk+ovs version with qemu version ?

i wanted to try dpdk or ovs upgrade alone, instead of both, but it has some
build dependencies, so i can't try that.

My earlier mail on this issue - https://www.mail-archive.
com/d...@openvswitch.org/msg71381.html .

Regards
Kapil.
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] Vhostports drop issue - related to MTU - Qemu version

[Kapil Adhikesavalu]

Hi Mark,

This commit is already part of 2.6.0 that i am using. Also, when i create
an port with mtu_request, it is creating with the expected mtu, no problems
here.

The issue i am facing is, i am not even able to run traffic through a
PHY-VM-PHY with the default MTU (mtu_request not used).
I am just creating the dpdk and vhostuser ports without mtu_request and all
the packets are getting dropped at vhostuser port

Working scenario:  DPDK16.04 + OVS2.5.9 + qemu 2.4.1 - default MTU 1500
Non-working scenario: * DPDK16.07 + OVS2.6.0* + qemu 2.4.1 - default MTU
1500.

When i reconfigure the default vhostuser mtu to a different value, packet
drop issue stop; Though issue pops up if the VM is rebooted.
I am trying to find why the default config wouldn't work with the above
dpdk,ovs,qemu version ?

Also doing qemu upgrade is resolving the issue - DPDK16.07 + OVS2.6.0 + *qemu
2.6.2* - default MTU 1500.
There are other dependencies for me in upgrading the qemu verson to 2.6.2,
so i am looking for a way to make it work with 2.4.1.

Regards
Kapil.

On Wed, Oct 26, 2016 at 7:42 PM, Kavanagh, Mark B  wrote:

> >
> >Hi,
> >
> >Issue Setup:  DPDK 16.07 + OVS 2.6.0 + qemu 2.4.1 : PHY-VM-PHY
> >
> >I am trying to upgrade from (DPDK16.04 + OVS2.5.9), to (DPDK16.07 +
> OVS2.6.0) for jumbo frame
> >support. After the upgrade, all packets are getting dropped on the
> vhostuser port.
> >The dpdk/vhost user ports used here has default MTU of 1500 and packets
> are within the MTU
> >size.
> >
> >Upon few trails, i found configuring the mtu on the vhostuser port is
> somehow fixing the drop
> >issue. Command used : ovs-vsctl set interface vhostuser1
> mtu_request=1400(to any value
> >works).
> >Though even with this, if i reboot the VM, again the drop issue shows up
> and mtu has to be
> >reconfigured/changed on the vhost to get the traffic working.
> >Seems, modifying the mtu value on vhost is internally triggering
> something which resolves the
> >drop issue.
> >
> >I upgraded the qemu to 2.6.2, which resolves the drop issue in the vhost
> ports without any
> >changes to default MTU.
> >I suspect, if its some interop issue with qemu 2.4.1, after the addition
> of jumbo frame
> >support in OVS 2.6.0.
> >
> >Some input on how to debug this will help. is there any dependency on
> dpdk+ovs version with
> >qemu version ?
>
> Hi Kapil,
>
> You should update OvS to the following commit, which resolves the MTU
> issue:
>
> commit 7c12e20006118e69a98f6840731ebf0c87582b4a
> Author: Daniele Di Proietto 
> Date:   Mon Aug 29 19:01:13 2016 -0700
>
> bridge: Honor 'mtu_request' when port is added.
>
> 'mtu_request' was honored only when the port was reconfigured, not
> when
>  the port was added.
>
> This commit fixes the problem and improves a testcase to detect
> the bug.
>
> Hope this helps,
> Mark
>
> >
> >i wanted to try dpdk or ovs upgrade alone, instead of both, but it has
> some build
> >dependencies, so i can't try that.
> >My earlier mail on this issue - https://www.mail-
> >archive.com/d...@openvswitch.org/msg71381.html .
> >
> >Regards
> >Kapil.
>
___
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Re: [ovs-discuss] Vhostports drop issue - related to MTU - Qemu version

[Kapil Adhikesavalu]

Thanks Mark, I will check this.

I am not using multi-queue and from this thread, they have already added a
change in OVS to support older version of QEMU(queue 0 is enabled in OVS
even if qemu doesnt send VRING_ENABLE), which is what helped me to use qemu
2.4.1 till OVS 2.5.9. are these threads related ?
http://openvswitch.org/pipermail/dev/2016-March/068430.html

http://openvswitch.org/pipermail/dev/2016-March/068429.html


netdev@ovs-netdev:
lookups: hit:36049 missed:8819 lost:0
flows: 14
port 0: ovs-netdev (tap)
port 1: br-dpdk0 (tap)
port 2: br-dpdk1 (tap)
port 3: dpdk0 (dpdk: configured_rx_queues=1,
configured_tx_queues=5, mtu=1500, requested_rx_queues=1,
requested_tx_queues=5)
port 4: dpdk1 (dpdk: configured_rx_queues=1,
configured_tx_queues=5, mtu=1500, requested_rx_queues=1,
requested_tx_queues=5)
port 5: vhost-1-0 (dpdkvhostuser: configured_rx_queues=1,
configured_tx_queues=1, mtu=1500, requested_rx_queues=1,
requested_tx_queues=1)
port 6: vhost-1-1 (dpdkvhostuser: configured_rx_queues=1,
configured_tx_queues=1, mtu=1500, requested_rx_queues=1,
requested_tx_queues=1)

[root@localhost ~]# ovs-appctl dpif-netdev/pmd-rxq-show
pmd thread numa_id 0 core_id 1:
isolated : false
port: vhost-1-0 queue-id: 0
port: dpdk1 queue-id: 0
port: vhost-1-1 queue-id: 0
port: dpdk0 queue-id: 0


On Wed, Oct 26, 2016 at 9:05 PM, Kavanagh, Mark B  wrote:

> >
> >Hi Mark,
> >
> >This commit is already part of 2.6.0 that i am using. Also, when i create
> an port with
> >mtu_request, it is creating with the expected mtu, no problems here.
> >
> >The issue i am facing is, i am not even able to run traffic through a
> PHY-VM-PHY with the
> >default MTU (mtu_request not used).
> >I am just creating the dpdk and vhostuser ports without mtu_request and
> all the packets are
> >getting dropped at vhostuser port
> >
> >Working scenario:  DPDK16.04 + OVS2.5.9 + qemu 2.4.1 - default MTU 1500
> >Non-working scenario:  DPDK16.07 + OVS2.6.0 + qemu 2.4.1 - default MTU
> 1500.
> >
> >When i reconfigure the default vhostuser mtu to a different value, packet
> drop issue stop;
> >Though issue pops up if the VM is rebooted.
> >I am trying to find why the default config wouldn't work with the above
> dpdk,ovs,qemu version
> >?
> >
> >Also doing qemu upgrade is resolving the issue - DPDK16.07 + OVS2.6.0 +
> qemu 2.6.2 - default
> >MTU 1500.
> >There are other dependencies for me in upgrading the qemu verson to
> 2.6.2, so i am looking
> >for a way to make it work with 2.4.1.
>
> I presume then that vhost user multiqueue support is the root cause here.
> Try applying the following commit to your QEMU tree - I'm guessing that it
> should resolve your issue:
>
> commit dc3db6adde329548771ab2addc2ef8376b2b8b32
> Author: Michael S. Tsirkin 
> Date:   Mon Nov 16 18:40:18 2015 +0200
>
> vhost-user: start/stop all rings
>
> We are currently only sending VRING_ENABLE message for the
> first ring,
> that's wrong: we must start/stop them all.
>
> Thanks,
> Mark
>
> >
> >Regards
> >Kapil.
> >
> >On Wed, Oct 26, 2016 at 7:42 PM, Kavanagh, Mark B <
> mark.b.kavan...@intel.com> wrote:
> >>
> >>Hi,
> >>
> >>Issue Setup:  DPDK 16.07 + OVS 2.6.0 + qemu 2.4.1 : PHY-VM-PHY
> >>
> >>I am trying to upgrade from (DPDK16.04 + OVS2.5.9), to (DPDK16.07 +
> OVS2.6.0) for jumbo
> >frame
> >>support. After the upgrade, all packets are getting dropped on the
> vhostuser port.
> >>The dpdk/vhost user ports used here has default MTU of 1500 and packets
> are within the MTU
> >>size.
> >>
> >>Upon few trails, i found configuring the mtu on the vhostuser port is
> somehow fixing the
> >drop
> >>issue. Command used : ovs-vsctl set interface vhostuser1
> mtu_request=1400(to any value
> >>works).
> >>Though even with this, if i reboot the VM, again the drop issue shows up
> and mtu has to be
> >>reconfigured/changed on the vhost to get the traffic working.
> >>Seems, modifying the mtu value on vhost is internally triggering
> something which resolves
> >the
> >>drop issue.
> >>
> >>I upgraded the qemu to 2.6.2, which resolves the drop issue in the vhost
> ports without any
> >>changes to default MTU.
> >>I suspect, if its some interop issue with qemu 2.4.1, after the addition
> of jumbo frame
> >>support in OVS 2.6.0.
> >>
> >>Some input on how to debug this will help. is there any dependency on
> dpdk+ovs version with
> >>qemu version ?
> >
> >Hi Kapil,
> >
> >You should update OvS to the following commit, which resolves the MTU
> issue:
> >
> >commit 7c12e20006118e69a98f6840731ebf0c87582b4a
> >Author: Daniele Di Proietto 
> >Date:   Mon Aug 29 19:01:13 2016 -0700
> >
> >bridge: Honor 'mtu_request' when port is added.
> >
> >'mtu_request' was honored only when the port was reconfigured,
> not when
> > the port was added.
> >
> >This