Re: [ovs-discuss] How to reset counters of ovs-flows ?

[Ben Pfaff]

If you can do without the flows momentarily, you could delete all the
flows and then replace them.

On Wed, Mar 29, 2017 at 10:28:13AM +0530, f 62 wrote:
> Getting this error with OpenFlow1.0
> 
> sudo ovs-ofctl -O OpenFlow10 --readd replace-flows br-int /tmp/br_int
> 
> ovs-ofctl: switch does not support any of the usable flow formats
> (OXM,NXM+table_id)
> 
> Is there any other way to achieve same ?
> 
> On Tue, Mar 28, 2017 at 10:17 PM, Ben Pfaff  wrote:
> 
> > On Tue, Mar 28, 2017 at 05:26:46PM +0530, f 62 wrote:
> > > I am trying to reset the counter of ovs-flows. I followed following
> > steps:
> > >
> > > a. ovs-ofctl -O Openflow13 dump-flows br-int > /tmp/br_int
> > >
> > > b. ovs-ofctl -O OpenFlow13 --readd replace-flows br-int /tmp/br_int
> > >
> > >
> > >  Its not working . Does it only work if the flow differs in the *file
> > *and
> > > in the *ovs *? How the counters can be resetted ?
> >
> > In OpenFlow 1.2 and later, flow_mod messages need to add a special
> > "reset counts" flag to reset the counters.  ovs-ofctl doesn't currently
> > provide a way to set that flag.  This is an oversight that should be
> > corrected.  Until then, if you can use OpenFlow 1.0, then that plus
> > --readd should allow you to reset the counters.
> >
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] How to reset counters of ovs-flows ?

[f 62]

Getting this error with OpenFlow1.0

sudo ovs-ofctl -O OpenFlow10 --readd replace-flows br-int /tmp/br_int

ovs-ofctl: switch does not support any of the usable flow formats
(OXM,NXM+table_id)

Is there any other way to achieve same ?

On Tue, Mar 28, 2017 at 10:17 PM, Ben Pfaff  wrote:

> On Tue, Mar 28, 2017 at 05:26:46PM +0530, f 62 wrote:
> > I am trying to reset the counter of ovs-flows. I followed following
> steps:
> >
> > a. ovs-ofctl -O Openflow13 dump-flows br-int > /tmp/br_int
> >
> > b. ovs-ofctl -O OpenFlow13 --readd replace-flows br-int /tmp/br_int
> >
> >
> >  Its not working . Does it only work if the flow differs in the *file
> *and
> > in the *ovs *? How the counters can be resetted ?
>
> In OpenFlow 1.2 and later, flow_mod messages need to add a special
> "reset counts" flag to reset the counters.  ovs-ofctl doesn't currently
> provide a way to set that flag.  This is an oversight that should be
> corrected.  Until then, if you can use OpenFlow 1.0, then that plus
> --readd should allow you to reset the counters.
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] VM-VM-VM communication via OVS

[Advith Nagappa]

Hello,

I meant VM1 - VM2(ovs) - VM3..

Yes, the host is Linux.

 The VMs are already connected without the OVS

I want to create a topology such that communication goes via OVS in VM3.




On Mar 29, 2017 01:03, "Yi Tseng"  wrote:

Hi

You mean:

VM1 -- VM2(with ovs) -- VM3 ?

or

VM1 -- ovs -- VM2 -- ovs -- VM3

I assume that your host system is Linux

You can create veth pairs.

And attach veth interfaces to VMs and ovs.

-Yi

2017-03-28 14:21 GMT-07:00 Justin Pettit :

>
> > On Mar 28, 2017, at 3:48 AM, Advith Nagappa 
> wrote:
> >
> > Hello All,
> >
> > Is it possible to link 2 guest VMS, via another guest VM using OVS
> bridge?
> >
> > Is anyone aware of any resource/doc covering this scenario?
>
> I don't understand the deployment scenario that you're describing.
> However, OVS can connect VMs in arbitrary topologies.
>
> --Justin
>
>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>



-- 
Yi Tseng (a.k.a Takeshi)
Taiwan National Chiao Tung University
Department of Computer Science
W2CNLab

https://takeshi.tw
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Error attaching device to DPDK

[Darrell Ball]

From:  on behalf of Brad Cowie 

Date: Tuesday, March 28, 2017 at 5:35 PM
To: Shivaram Mysore 
Cc: "ovs-discuss@openvswitch.org" 
Subject: Re: [ovs-discuss] Error attaching device to DPDK

Hi folks,
I have been helping Shivaram off-list with this problem and just wanted to 
update this thread with the solution.
Basically the issue was with how hugepages were being preallocated by OVS for 
use with DPDK. I believe by default OVS sets other_config:dpdk-socket-mem to 
"1024,0". Which will give one 1GB hugepage to CPU0 and none to CPU1.
The ports Shivaram was trying to assign to DPDK were connected physically via a 
PCI-E bus to CPU1 and since there are no hugepages preallocated there for DPDK 
then we can't add it.
The fix is simple, to assign a hugepage to CPU1:

$ sudo ovs-vsctl --no-wait set Open_vSwitch . 
other_config:dpdk-socket-mem="1024,1024"
In OVS 2.7.0 unfortunately due to an issue (that is now fixed by commit 
ef6cca6fdc67f3cee21c6bb1c13c4ca7f8241314) you get a segfault rather than an 
error message telling you the problem.
In OVS 2.7.90 however the issue becomes quite clear as there is a nice log 
message like such:

2017-03-29T00:19:57Z|00067|netdev_dpdk|ERR|Insufficient memory to create memory 
pool for netdev dpdk-p0, with MTU 1500 on socket 1
There is documentation regarding these fields, but for case, the documentation 
could simply state something like
“you need to allocate hugepage memory on each numa node where dpdk ports are 
bound and or those ports
will not work with dpdk”
The error log could also be a little more succinct like “no memory pool 
allocated for netdev dpdk-p0,.., usage on socket 1”

Possibly, going even further, when a PMD thread gets auto-allocated to run on a 
given numa node,
memory allocation is defaulted there as well. If it cannot be allocated, an 
error log is generated.

Unfortunately to those unfamiliar with DPDK and NUMA architectures this won't 
be very obvious. Potentially we could add some additional help to the DPDK 
documentation pages for OVS that explains the other_config options you may need 
to reconfigure on multi-CPU NUMA machines?
Brad

On 29 March 2017 at 10:02, Shivaram Mysore 
> wrote:
Ok thanks.  Will remember the same.  Right now, I will not specify anything as 
I have to get this to work first!

On Tue, Mar 28, 2017 at 2:00 PM, Bodireddy, Bhanuprakash 
> 
wrote:
>Question:
>
>I don't have any specific cpu cores associated with DPDK.  Will this make any
>difference?  I also did not see this requirement as a MUST have in the
>documentation.

I assume your question is on PMD threads. If you don’t specify any thing 
explicitly
PMD pmd thread shall be created and pinned to core 0.  You can explicitly 
select the no. of pmd threads
and the cores by explicitly setting the affinity mask using 
'other_config:pmd-cpu-mask'.

Based on the affinity mask, the PMD threads shall be spawned and the rx queues 
will be uniformly
distributed among the PMD threads.

Refer 
http://docs.openvswitch.org/en/latest/howto/dpdk/.

Also note that 'dpdk-lcore-mask' should be used to set the dpdk lcore threads 
and vswitchd.

- Bhanuprakash.

>
># cat /proc/cmdline
>BOOT_IMAGE=/boot/vmlinuz-4.10.0-14-generic root=/dev/mapper/intelsdn-
>-vg-root ro quiet intel_iommu=on iommu=pt default_hugepagesz=1G
>hugepagesz=1G hugepages=4
>
>
>Thanks
>
>/Shivaram
>
>On Tue, Mar 28, 2017 at 1:32 PM, Shivaram Mysore
>> wrote:
>I was advised on this mailing list that VFIO drivers are better than IGB_UIO +
>more forgiving [1].  Hence switched to the same.
>
>[1] 
>http://dpdk-guide.gitlab.io/dpdk-guide/setup/binding.html
>
>/Shivaram
>
>On Tue, Mar 28, 2017 at 1:12 PM, Bodireddy, Bhanuprakash
>> 
>wrote:
>
>>any hints for me based on the info provided?
>
>Your BIOS options and bootcmd line options are appropriate and no issues
>there. I wanted to check if you tried igb_uio drivers
>but saw your post here 

Re: [ovs-discuss] Error attaching device to DPDK

[Shivaram Mysore]

Once again thanks to Brad for helping me resolve this issue.

One other thing that I could suggest is that to throw a WARN message in the
logs if more than 1 CPU is found and memory is not set for all CPUs
especially when using DPDK.

My read on the situation was that memory was going to be allocated to all
CPUs per hugepage settings. But, that is for the system and this would be
for OVS.  So, a log message to that effect would be very welcome.

Thanks to all for chipping in and helping out.

Regards

/Shivaram

On Tue, Mar 28, 2017 at 5:35 PM, Brad Cowie  wrote:

> Hi folks,
>
> I have been helping Shivaram off-list with this problem and just wanted to
> update this thread with the solution.
>
> Basically the issue was with how hugepages were being preallocated by OVS
> for use with DPDK. I believe by default OVS sets
> other_config:dpdk-socket-mem to "1024,0". Which will give one 1GB hugepage
> to CPU0 and none to CPU1.
>
> The ports Shivaram was trying to assign to DPDK were connected physically
> via a PCI-E bus to CPU1 and since there are no hugepages preallocated there
> for DPDK then we can't add it.
>
> The fix is simple, to assign a hugepage to CPU1:
>
> $ sudo ovs-vsctl --no-wait set Open_vSwitch .
> other_config:dpdk-socket-mem="1024,1024"
>
> In OVS 2.7.0 unfortunately due to an issue (that is now fixed by commit
> ef6cca6fdc67f3cee21c6bb1c13c4ca7f8241314) you get a segfault rather than
> an error message telling you the problem.
>
> In OVS 2.7.90 however the issue becomes quite clear as there is a nice log
> message like such:
>
> 2017-03-29T00:19:57Z|00067|netdev_dpdk|ERR|Insufficient memory to create
> memory pool for netdev dpdk-p0, with MTU 1500 on socket 1
>
> Unfortunately to those unfamiliar with DPDK and NUMA architectures this
> won't be very obvious. Potentially we could add some additional help to the
> DPDK documentation pages for OVS that explains the other_config options you
> may need to reconfigure on multi-CPU NUMA machines?
>
> Brad
>
> On 29 March 2017 at 10:02, Shivaram Mysore 
> wrote:
>
>> Ok thanks.  Will remember the same.  Right now, I will not specify
>> anything as I have to get this to work first!
>>
>> On Tue, Mar 28, 2017 at 2:00 PM, Bodireddy, Bhanuprakash <
>> bhanuprakash.bodire...@intel.com> wrote:
>>
>>> >Question:
>>> >
>>> >I don't have any specific cpu cores associated with DPDK.  Will this
>>> make any
>>> >difference?  I also did not see this requirement as a MUST have in the
>>> >documentation.
>>>
>>> I assume your question is on PMD threads. If you don’t specify any thing
>>> explicitly
>>> PMD pmd thread shall be created and pinned to core 0.  You can
>>> explicitly select the no. of pmd threads
>>> and the cores by explicitly setting the affinity mask using
>>> 'other_config:pmd-cpu-mask'.
>>>
>>> Based on the affinity mask, the PMD threads shall be spawned and the rx
>>> queues will be uniformly
>>> distributed among the PMD threads.
>>>
>>> Refer http://docs.openvswitch.org/en/latest/howto/dpdk/.
>>>
>>> Also note that 'dpdk-lcore-mask' should be used to set the dpdk lcore
>>> threads and vswitchd.
>>>
>>> - Bhanuprakash.
>>>
>>> >
>>> ># cat /proc/cmdline
>>> >BOOT_IMAGE=/boot/vmlinuz-4.10.0-14-generic root=/dev/mapper/intelsdn-
>>> >-vg-root ro quiet intel_iommu=on iommu=pt default_hugepagesz=1G
>>> >hugepagesz=1G hugepages=4
>>> >
>>> >
>>> >Thanks
>>> >
>>> >/Shivaram
>>> >
>>> >On Tue, Mar 28, 2017 at 1:32 PM, Shivaram Mysore
>>> > wrote:
>>> >I was advised on this mailing list that VFIO drivers are better than
>>> IGB_UIO +
>>> >more forgiving [1].  Hence switched to the same.
>>> >
>>> >[1] http://dpdk-guide.gitlab.io/dpdk-guide/setup/binding.html
>>> >
>>> >/Shivaram
>>> >
>>> >On Tue, Mar 28, 2017 at 1:12 PM, Bodireddy, Bhanuprakash
>>> > wrote:
>>> >
>>> >>any hints for me based on the info provided?
>>> >
>>> >Your BIOS options and bootcmd line options are appropriate and no issues
>>> >there. I wanted to check if you tried igb_uio drivers
>>> >but saw your post here https://mail.openvswitch.org/pipermail/ovs-
>>> >discuss/2017-March/043993.html, reporting a crash with UIO drivers.
>>> >
>>> >Is that the reason why you moved to VFIO? I cross checked your logs but
>>> >found nothing suspicious there.
>>> >
>>> >-Bhanuprakash.
>>> >
>>> >>
>>> >>Thanks
>>> >>
>>> >>On Tue, Mar 28, 2017 at 8:41 AM, Shivaram Mysore
>>> >> wrote:
>>> >>Hi,
>>> >>
>>> >># dmesg | grep -e DMAR -e IOMMU
>>> >>[0.00] ACPI: DMAR 0x798AF340 000158 (v01 SUPERM SMCI--
>>> >>MB 0001 INTL 20091013)
>>> >>[0.00] DMAR: IOMMU enabled
>>> >>[0.109987] DMAR: Host address width 46
>>> >>[0.109988] DMAR: DRHD base: 0x00fbffc000 flags: 0x0
>>> >>[0.109997] DMAR: dmar0: reg_base_addr fbffc000 ver 1:0 cap
>>> >>d2078c106f0466 ecap f020de
>>> >>[0.109998] DMAR: DRHD base: 0x00c7ffc000 flags: 0x1
>>> 

Re: [ovs-discuss] Error attaching device to DPDK

[Brad Cowie]

Hi folks,

I have been helping Shivaram off-list with this problem and just wanted to
update this thread with the solution.

Basically the issue was with how hugepages were being preallocated by OVS
for use with DPDK. I believe by default OVS sets
other_config:dpdk-socket-mem to "1024,0". Which will give one 1GB hugepage
to CPU0 and none to CPU1.

The ports Shivaram was trying to assign to DPDK were connected physically
via a PCI-E bus to CPU1 and since there are no hugepages preallocated there
for DPDK then we can't add it.

The fix is simple, to assign a hugepage to CPU1:

$ sudo ovs-vsctl --no-wait set Open_vSwitch .
other_config:dpdk-socket-mem="1024,1024"

In OVS 2.7.0 unfortunately due to an issue (that is now fixed by commit
ef6cca6fdc67f3cee21c6bb1c13c4ca7f8241314) you get a segfault rather than an
error message telling you the problem.

In OVS 2.7.90 however the issue becomes quite clear as there is a nice log
message like such:

2017-03-29T00:19:57Z|00067|netdev_dpdk|ERR|Insufficient memory to create
memory pool for netdev dpdk-p0, with MTU 1500 on socket 1

Unfortunately to those unfamiliar with DPDK and NUMA architectures this
won't be very obvious. Potentially we could add some additional help to the
DPDK documentation pages for OVS that explains the other_config options you
may need to reconfigure on multi-CPU NUMA machines?

Brad

On 29 March 2017 at 10:02, Shivaram Mysore 
wrote:

> Ok thanks.  Will remember the same.  Right now, I will not specify
> anything as I have to get this to work first!
>
> On Tue, Mar 28, 2017 at 2:00 PM, Bodireddy, Bhanuprakash <
> bhanuprakash.bodire...@intel.com> wrote:
>
>> >Question:
>> >
>> >I don't have any specific cpu cores associated with DPDK.  Will this
>> make any
>> >difference?  I also did not see this requirement as a MUST have in the
>> >documentation.
>>
>> I assume your question is on PMD threads. If you don’t specify any thing
>> explicitly
>> PMD pmd thread shall be created and pinned to core 0.  You can explicitly
>> select the no. of pmd threads
>> and the cores by explicitly setting the affinity mask using
>> 'other_config:pmd-cpu-mask'.
>>
>> Based on the affinity mask, the PMD threads shall be spawned and the rx
>> queues will be uniformly
>> distributed among the PMD threads.
>>
>> Refer http://docs.openvswitch.org/en/latest/howto/dpdk/.
>>
>> Also note that 'dpdk-lcore-mask' should be used to set the dpdk lcore
>> threads and vswitchd.
>>
>> - Bhanuprakash.
>>
>> >
>> ># cat /proc/cmdline
>> >BOOT_IMAGE=/boot/vmlinuz-4.10.0-14-generic root=/dev/mapper/intelsdn-
>> >-vg-root ro quiet intel_iommu=on iommu=pt default_hugepagesz=1G
>> >hugepagesz=1G hugepages=4
>> >
>> >
>> >Thanks
>> >
>> >/Shivaram
>> >
>> >On Tue, Mar 28, 2017 at 1:32 PM, Shivaram Mysore
>> > wrote:
>> >I was advised on this mailing list that VFIO drivers are better than
>> IGB_UIO +
>> >more forgiving [1].  Hence switched to the same.
>> >
>> >[1] http://dpdk-guide.gitlab.io/dpdk-guide/setup/binding.html
>> >
>> >/Shivaram
>> >
>> >On Tue, Mar 28, 2017 at 1:12 PM, Bodireddy, Bhanuprakash
>> > wrote:
>> >
>> >>any hints for me based on the info provided?
>> >
>> >Your BIOS options and bootcmd line options are appropriate and no issues
>> >there. I wanted to check if you tried igb_uio drivers
>> >but saw your post here https://mail.openvswitch.org/pipermail/ovs-
>> >discuss/2017-March/043993.html, reporting a crash with UIO drivers.
>> >
>> >Is that the reason why you moved to VFIO? I cross checked your logs but
>> >found nothing suspicious there.
>> >
>> >-Bhanuprakash.
>> >
>> >>
>> >>Thanks
>> >>
>> >>On Tue, Mar 28, 2017 at 8:41 AM, Shivaram Mysore
>> >> wrote:
>> >>Hi,
>> >>
>> >># dmesg | grep -e DMAR -e IOMMU
>> >>[0.00] ACPI: DMAR 0x798AF340 000158 (v01 SUPERM SMCI--
>> >>MB 0001 INTL 20091013)
>> >>[0.00] DMAR: IOMMU enabled
>> >>[0.109987] DMAR: Host address width 46
>> >>[0.109988] DMAR: DRHD base: 0x00fbffc000 flags: 0x0
>> >>[0.109997] DMAR: dmar0: reg_base_addr fbffc000 ver 1:0 cap
>> >>d2078c106f0466 ecap f020de
>> >>[0.109998] DMAR: DRHD base: 0x00c7ffc000 flags: 0x1
>> >>[0.110002] DMAR: dmar1: reg_base_addr c7ffc000 ver 1:0 cap
>> >>d2078c106f0466 ecap f020de
>> >>[0.110003] DMAR: RMRR base: 0x007ba75000 end: 0x007ba84fff
>> >>[0.110004] DMAR: ATSR flags: 0x0
>> >>[0.110005] DMAR: RHSA base: 0x00c7ffc000 proximity domain: 0x0
>> >>[0.110006] DMAR: RHSA base: 0x00fbffc000 proximity domain: 0x1
>> >>[0.110008] DMAR-IR: IOAPIC id 3 under DRHD base  0xfbffc000 IOMMU 0
>> >>[0.110008] DMAR-IR: IOAPIC id 1 under DRHD base  0xc7ffc000 IOMMU 1
>> >>[0.110009] DMAR-IR: IOAPIC id 2 under DRHD base  0xc7ffc000 IOMMU 1
>> >>[0.110010] DMAR-IR: HPET id 0 under DRHD base 0xc7ffc000
>> >>[0.110011] DMAR-IR: x2apic is disabled because BIOS sets 

Re: [ovs-discuss] Centralizing OVS-DPDK Blogs

[Justin Pettit]

> On Mar 28, 2017, at 4:15 AM, Stokes, Ian  wrote:
> 
> Hi All,
> 
> There are a number of useful blogs maintained by Intel for OVS-DPDK. These 
> range from simple 'how-to' articles for specific feature to more technical 
> deep dives of how features work under the hood.
> 
> Currently these blogs are hosted on the Intel Developer Zone (and will 
> continue to be), but there have been suggestions that it could be useful to 
> expose them in a more central manner to OVS users.
> 
> This could include one or more of the following
> 
> 1. Expand existing OVS docs with blog content.
> 2. Adding the blogs to the OVS cookbook.
> 3. Creating a news feed for OVS using something like the Planet feed reader 
> for the OVS webpage. (http://www.planetplanet.org/)
> 
> This issue was raised at the OVS-DPDK community meeting and it was decided to 
> kick off a community discussion for more input before taking action.
> 
> Do people feel centralizing OVS-DPDK content to the OVS project would be 
> useful or is the status quo preferred?

Thanks for bringing this up.  For basic documentation, I think it makes sense 
to expand the existing docs where appropriate.

We've talked about adding some cookbook-like documentation for OVN.  It would 
be nice to use the same mechanism for both.  In the past, we've hosted 
cookbooks on the main OVS website, but they weren't regularly updated, and sort 
of fell into disrepair.  A good path forward might be to introduce them into 
the OVS repo, since they're now displayed nicely through Read the Docs 
(https://readthedocs.org).

I'd be curious to get others' opinions--especially Ben and Stephen since they 
were so involved in the last documentation overhaul.

--Justin


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] VM-VM-VM communication via OVS

[Yi Tseng]

Hi

You mean:

VM1 -- VM2(with ovs) -- VM3 ?

or

VM1 -- ovs -- VM2 -- ovs -- VM3

I assume that your host system is Linux

You can create veth pairs.

And attach veth interfaces to VMs and ovs.

-Yi

2017-03-28 14:21 GMT-07:00 Justin Pettit :

>
> > On Mar 28, 2017, at 3:48 AM, Advith Nagappa 
> wrote:
> >
> > Hello All,
> >
> > Is it possible to link 2 guest VMS, via another guest VM using OVS
> bridge?
> >
> > Is anyone aware of any resource/doc covering this scenario?
>
> I don't understand the deployment scenario that you're describing.
> However, OVS can connect VMs in arbitrary topologies.
>
> --Justin
>
>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>



-- 
Yi Tseng (a.k.a Takeshi)
Taiwan National Chiao Tung University
Department of Computer Science
W2CNLab

https://takeshi.tw
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] VM-VM-VM communication via OVS

[Justin Pettit]

> On Mar 28, 2017, at 3:48 AM, Advith Nagappa  wrote:
> 
> Hello All,
> 
> Is it possible to link 2 guest VMS, via another guest VM using OVS bridge?
> 
> Is anyone aware of any resource/doc covering this scenario?

I don't understand the deployment scenario that you're describing.  However, 
OVS can connect VMs in arbitrary topologies.

--Justin


___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Error attaching device to DPDK

[Shivaram Mysore]

Ok thanks.  Will remember the same.  Right now, I will not specify anything
as I have to get this to work first!

On Tue, Mar 28, 2017 at 2:00 PM, Bodireddy, Bhanuprakash <
bhanuprakash.bodire...@intel.com> wrote:

> >Question:
> >
> >I don't have any specific cpu cores associated with DPDK.  Will this make
> any
> >difference?  I also did not see this requirement as a MUST have in the
> >documentation.
>
> I assume your question is on PMD threads. If you don’t specify any thing
> explicitly
> PMD pmd thread shall be created and pinned to core 0.  You can explicitly
> select the no. of pmd threads
> and the cores by explicitly setting the affinity mask using
> 'other_config:pmd-cpu-mask'.
>
> Based on the affinity mask, the PMD threads shall be spawned and the rx
> queues will be uniformly
> distributed among the PMD threads.
>
> Refer http://docs.openvswitch.org/en/latest/howto/dpdk/.
>
> Also note that 'dpdk-lcore-mask' should be used to set the dpdk lcore
> threads and vswitchd.
>
> - Bhanuprakash.
>
> >
> ># cat /proc/cmdline
> >BOOT_IMAGE=/boot/vmlinuz-4.10.0-14-generic root=/dev/mapper/intelsdn-
> >-vg-root ro quiet intel_iommu=on iommu=pt default_hugepagesz=1G
> >hugepagesz=1G hugepages=4
> >
> >
> >Thanks
> >
> >/Shivaram
> >
> >On Tue, Mar 28, 2017 at 1:32 PM, Shivaram Mysore
> > wrote:
> >I was advised on this mailing list that VFIO drivers are better than
> IGB_UIO +
> >more forgiving [1].  Hence switched to the same.
> >
> >[1] http://dpdk-guide.gitlab.io/dpdk-guide/setup/binding.html
> >
> >/Shivaram
> >
> >On Tue, Mar 28, 2017 at 1:12 PM, Bodireddy, Bhanuprakash
> > wrote:
> >
> >>any hints for me based on the info provided?
> >
> >Your BIOS options and bootcmd line options are appropriate and no issues
> >there. I wanted to check if you tried igb_uio drivers
> >but saw your post here https://mail.openvswitch.org/pipermail/ovs-
> >discuss/2017-March/043993.html, reporting a crash with UIO drivers.
> >
> >Is that the reason why you moved to VFIO? I cross checked your logs but
> >found nothing suspicious there.
> >
> >-Bhanuprakash.
> >
> >>
> >>Thanks
> >>
> >>On Tue, Mar 28, 2017 at 8:41 AM, Shivaram Mysore
> >> wrote:
> >>Hi,
> >>
> >># dmesg | grep -e DMAR -e IOMMU
> >>[0.00] ACPI: DMAR 0x798AF340 000158 (v01 SUPERM SMCI--
> >>MB 0001 INTL 20091013)
> >>[0.00] DMAR: IOMMU enabled
> >>[0.109987] DMAR: Host address width 46
> >>[0.109988] DMAR: DRHD base: 0x00fbffc000 flags: 0x0
> >>[0.109997] DMAR: dmar0: reg_base_addr fbffc000 ver 1:0 cap
> >>d2078c106f0466 ecap f020de
> >>[0.109998] DMAR: DRHD base: 0x00c7ffc000 flags: 0x1
> >>[0.110002] DMAR: dmar1: reg_base_addr c7ffc000 ver 1:0 cap
> >>d2078c106f0466 ecap f020de
> >>[0.110003] DMAR: RMRR base: 0x007ba75000 end: 0x007ba84fff
> >>[0.110004] DMAR: ATSR flags: 0x0
> >>[0.110005] DMAR: RHSA base: 0x00c7ffc000 proximity domain: 0x0
> >>[0.110006] DMAR: RHSA base: 0x00fbffc000 proximity domain: 0x1
> >>[0.110008] DMAR-IR: IOAPIC id 3 under DRHD base  0xfbffc000 IOMMU 0
> >>[0.110008] DMAR-IR: IOAPIC id 1 under DRHD base  0xc7ffc000 IOMMU 1
> >>[0.110009] DMAR-IR: IOAPIC id 2 under DRHD base  0xc7ffc000 IOMMU 1
> >>[0.110010] DMAR-IR: HPET id 0 under DRHD base 0xc7ffc000
> >>[0.110011] DMAR-IR: x2apic is disabled because BIOS sets x2apic opt
> out
> >bit.
> >>[0.110012] DMAR-IR: Use 'intremap=no_x2apic_optout' to override the
> >>BIOS setting.
> >>[0.110902] DMAR-IR: Enabled IRQ remapping in xapic mode
> >>[1.687595] DMAR: dmar0: Using Queued invalidation
> >>[1.687608] DMAR: dmar1: Using Queued invalidation
> >>[1.688473] DMAR: Hardware identity mapping for device :ff:08.0
> >>[1.688475] DMAR: Hardware identity mapping for device :ff:08.2
> >>[1.688477] DMAR: Hardware identity mapping for device :ff:08.3
> >>[1.688478] DMAR: Hardware identity mapping for device :ff:09.0
> >>[1.688480] DMAR: Hardware identity mapping for device :ff:09.2
> >>[1.688482] DMAR: Hardware identity mapping for device :ff:09.3
> >>[1.688483] DMAR: Hardware identity mapping for device :ff:0b.0
> >>[1.688485] DMAR: Hardware identity mapping for device :ff:0b.1
> >>[1.688487] DMAR: Hardware identity mapping for device :ff:0b.2
> >>[1.688488] DMAR: Hardware identity mapping for device :ff:0c.0
> >>[1.688490] DMAR: Hardware identity mapping for device :ff:0c.1
> >>[1.688491] DMAR: Hardware identity mapping for device :ff:0c.2
> >>[1.688493] DMAR: Hardware identity mapping for device :ff:0c.3
> >>[1.688494] DMAR: Hardware identity mapping for device :ff:0c.4
> >>[1.688496] DMAR: Hardware identity mapping for device :ff:0c.5
> >>[1.688498] DMAR: Hardware identity mapping for device :ff:0c.6
> >>[1.688499] DMAR: Hardware identity mapping 

Re: [ovs-discuss] Error attaching device to DPDK

[Bodireddy, Bhanuprakash]

>Question:
>
>I don't have any specific cpu cores associated with DPDK.  Will this make any
>difference?  I also did not see this requirement as a MUST have in the
>documentation.

I assume your question is on PMD threads. If you don’t specify any thing 
explicitly
PMD pmd thread shall be created and pinned to core 0.  You can explicitly 
select the no. of pmd threads
and the cores by explicitly setting the affinity mask using 
'other_config:pmd-cpu-mask'. 

Based on the affinity mask, the PMD threads shall be spawned and the rx queues 
will be uniformly
distributed among the PMD threads.

Refer http://docs.openvswitch.org/en/latest/howto/dpdk/.

Also note that 'dpdk-lcore-mask' should be used to set the dpdk lcore threads 
and vswitchd. 

- Bhanuprakash. 

>
># cat /proc/cmdline
>BOOT_IMAGE=/boot/vmlinuz-4.10.0-14-generic root=/dev/mapper/intelsdn-
>-vg-root ro quiet intel_iommu=on iommu=pt default_hugepagesz=1G
>hugepagesz=1G hugepages=4
>
>
>Thanks
>
>/Shivaram
>
>On Tue, Mar 28, 2017 at 1:32 PM, Shivaram Mysore
> wrote:
>I was advised on this mailing list that VFIO drivers are better than IGB_UIO +
>more forgiving [1].  Hence switched to the same.
>
>[1] http://dpdk-guide.gitlab.io/dpdk-guide/setup/binding.html
>
>/Shivaram
>
>On Tue, Mar 28, 2017 at 1:12 PM, Bodireddy, Bhanuprakash
> wrote:
>
>>any hints for me based on the info provided?
>
>Your BIOS options and bootcmd line options are appropriate and no issues
>there. I wanted to check if you tried igb_uio drivers
>but saw your post here https://mail.openvswitch.org/pipermail/ovs-
>discuss/2017-March/043993.html, reporting a crash with UIO drivers.
>
>Is that the reason why you moved to VFIO? I cross checked your logs but
>found nothing suspicious there.
>
>-Bhanuprakash.
>
>>
>>Thanks
>>
>>On Tue, Mar 28, 2017 at 8:41 AM, Shivaram Mysore
>> wrote:
>>Hi,
>>
>># dmesg | grep -e DMAR -e IOMMU
>>[    0.00] ACPI: DMAR 0x798AF340 000158 (v01 SUPERM SMCI--
>>MB 0001 INTL 20091013)
>>[    0.00] DMAR: IOMMU enabled
>>[    0.109987] DMAR: Host address width 46
>>[    0.109988] DMAR: DRHD base: 0x00fbffc000 flags: 0x0
>>[    0.109997] DMAR: dmar0: reg_base_addr fbffc000 ver 1:0 cap
>>d2078c106f0466 ecap f020de
>>[    0.109998] DMAR: DRHD base: 0x00c7ffc000 flags: 0x1
>>[    0.110002] DMAR: dmar1: reg_base_addr c7ffc000 ver 1:0 cap
>>d2078c106f0466 ecap f020de
>>[    0.110003] DMAR: RMRR base: 0x007ba75000 end: 0x007ba84fff
>>[    0.110004] DMAR: ATSR flags: 0x0
>>[    0.110005] DMAR: RHSA base: 0x00c7ffc000 proximity domain: 0x0
>>[    0.110006] DMAR: RHSA base: 0x00fbffc000 proximity domain: 0x1
>>[    0.110008] DMAR-IR: IOAPIC id 3 under DRHD base  0xfbffc000 IOMMU 0
>>[    0.110008] DMAR-IR: IOAPIC id 1 under DRHD base  0xc7ffc000 IOMMU 1
>>[    0.110009] DMAR-IR: IOAPIC id 2 under DRHD base  0xc7ffc000 IOMMU 1
>>[    0.110010] DMAR-IR: HPET id 0 under DRHD base 0xc7ffc000
>>[    0.110011] DMAR-IR: x2apic is disabled because BIOS sets x2apic opt out
>bit.
>>[    0.110012] DMAR-IR: Use 'intremap=no_x2apic_optout' to override the
>>BIOS setting.
>>[    0.110902] DMAR-IR: Enabled IRQ remapping in xapic mode
>>[    1.687595] DMAR: dmar0: Using Queued invalidation
>>[    1.687608] DMAR: dmar1: Using Queued invalidation
>>[    1.688473] DMAR: Hardware identity mapping for device :ff:08.0
>>[    1.688475] DMAR: Hardware identity mapping for device :ff:08.2
>>[    1.688477] DMAR: Hardware identity mapping for device :ff:08.3
>>[    1.688478] DMAR: Hardware identity mapping for device :ff:09.0
>>[    1.688480] DMAR: Hardware identity mapping for device :ff:09.2
>>[    1.688482] DMAR: Hardware identity mapping for device :ff:09.3
>>[    1.688483] DMAR: Hardware identity mapping for device :ff:0b.0
>>[    1.688485] DMAR: Hardware identity mapping for device :ff:0b.1
>>[    1.688487] DMAR: Hardware identity mapping for device :ff:0b.2
>>[    1.688488] DMAR: Hardware identity mapping for device :ff:0c.0
>>[    1.688490] DMAR: Hardware identity mapping for device :ff:0c.1
>>[    1.688491] DMAR: Hardware identity mapping for device :ff:0c.2
>>[    1.688493] DMAR: Hardware identity mapping for device :ff:0c.3
>>[    1.688494] DMAR: Hardware identity mapping for device :ff:0c.4
>>[    1.688496] DMAR: Hardware identity mapping for device :ff:0c.5
>>[    1.688498] DMAR: Hardware identity mapping for device :ff:0c.6
>>[    1.688499] DMAR: Hardware identity mapping for device :ff:0c.7
>>[    1.688500] DMAR: Hardware identity mapping for device :ff:0d.0
>>[    1.688502] DMAR: Hardware identity mapping for device :ff:0d.1
>>[    1.688504] DMAR: Hardware identity mapping for device :ff:0d.2
>>[    1.688505] DMAR: Hardware identity mapping for device :ff:0d.3
>>[    1.688506] DMAR: Hardware identity mapping for device :ff:0d.4
>>[    1.688508] DMAR: Hardware 

Re: [ovs-discuss] in mininet

[Guang Yang]

Hi:

How can I implement this if I want to create:
oxm_type=example, oxm_hasmask=1, oxm_length=4, oxm_value=0x7060,
oxm_mask=0xFF00
can I use ovs-ofctl add-flow? and how?

Regards,
Guang

On 24 March 2017 at 19:03, Ben Pfaff  wrote:

> It sounds like you need the source code.
>
> On Thu, Mar 23, 2017 at 05:22:26PM +0100, Guang Yang wrote:
> > I am trying to use OXM to add match fields in the flows. Like I have
> > attribute values from each package, and want to use them to manage the
> > network.
> >
> > On 23 March 2017 at 17:04, Ben Pfaff  wrote:
> >
> > > Please don't drop the list.
> > >
> > > What are you trying to do?
> > >
> > > On Thu, Mar 23, 2017 at 04:57:26PM +0100, Guang Yang wrote:
> > > > I have upgraded to latest version now, and realized the solution in
> the
> > > FAQ has not been updated. Any suggestions?
> > > >
> > > > Sent from my iPhone
> > > >
> > > > >> On 23 Mar 2017, at 16:26, Ben Pfaff  wrote:
> > > > >>
> > > > >> On Thu, Mar 23, 2017 at 12:55:12PM +0100, Guang Yang wrote:
> > > > >> I am quite new to the openvswitch, and I am a bit confused now.
> > > > >> I have mininet installed and running, when I use command:
> > > > >> ovs-ofctl --version
> > > > >> it shows: ovs-ofctl (Open vSwitch) 2.0.2
> > > > >>
> > > > >> I am not sure if this is the same tool as :
> > > > >> https://github.com/openvswitch/ovs
> > > > >
> > > > > It's a very old version.  Perhaps you should upgrade.
> > >
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Error attaching device to DPDK

[Shivaram Mysore]

Question:

I don't have any specific cpu cores associated with DPDK.  Will this make
any difference?  I also did not see this requirement as a MUST have in the
documentation.

#* cat /proc/cmdline*
BOOT_IMAGE=/boot/vmlinuz-4.10.0-14-generic
root=/dev/mapper/intelsdn--vg-root ro quiet intel_iommu=on iommu=pt
default_hugepagesz=1G hugepagesz=1G hugepages=4


Thanks

/Shivaram

On Tue, Mar 28, 2017 at 1:32 PM, Shivaram Mysore 
wrote:

> I was advised on this mailing list that VFIO drivers are better than
> IGB_UIO + more forgiving [1].  Hence switched to the same.
>
> [1] http://dpdk-guide.gitlab.io/dpdk-guide/setup/binding.html
>
> /Shivaram
>
> On Tue, Mar 28, 2017 at 1:12 PM, Bodireddy, Bhanuprakash <
> bhanuprakash.bodire...@intel.com> wrote:
>
>>
>> >any hints for me based on the info provided?
>>
>> Your BIOS options and bootcmd line options are appropriate and no issues
>> there. I wanted to check if you tried igb_uio drivers
>> but saw your post here https://mail.openvswitch.org/p
>> ipermail/ovs-discuss/2017-March/043993.html, reporting a crash with UIO
>> drivers.
>>
>> Is that the reason why you moved to VFIO? I cross checked your logs but
>> found nothing suspicious there.
>>
>> -Bhanuprakash.
>>
>> >
>> >Thanks
>> >
>> >On Tue, Mar 28, 2017 at 8:41 AM, Shivaram Mysore
>> > wrote:
>> >Hi,
>> >
>> ># dmesg | grep -e DMAR -e IOMMU
>> >[0.00] ACPI: DMAR 0x798AF340 000158 (v01 SUPERM SMCI--
>> >MB 0001 INTL 20091013)
>> >[0.00] DMAR: IOMMU enabled
>> >[0.109987] DMAR: Host address width 46
>> >[0.109988] DMAR: DRHD base: 0x00fbffc000 flags: 0x0
>> >[0.109997] DMAR: dmar0: reg_base_addr fbffc000 ver 1:0 cap
>> >d2078c106f0466 ecap f020de
>> >[0.109998] DMAR: DRHD base: 0x00c7ffc000 flags: 0x1
>> >[0.110002] DMAR: dmar1: reg_base_addr c7ffc000 ver 1:0 cap
>> >d2078c106f0466 ecap f020de
>> >[0.110003] DMAR: RMRR base: 0x007ba75000 end: 0x007ba84fff
>> >[0.110004] DMAR: ATSR flags: 0x0
>> >[0.110005] DMAR: RHSA base: 0x00c7ffc000 proximity domain: 0x0
>> >[0.110006] DMAR: RHSA base: 0x00fbffc000 proximity domain: 0x1
>> >[0.110008] DMAR-IR: IOAPIC id 3 under DRHD base  0xfbffc000 IOMMU 0
>> >[0.110008] DMAR-IR: IOAPIC id 1 under DRHD base  0xc7ffc000 IOMMU 1
>> >[0.110009] DMAR-IR: IOAPIC id 2 under DRHD base  0xc7ffc000 IOMMU 1
>> >[0.110010] DMAR-IR: HPET id 0 under DRHD base 0xc7ffc000
>> >[0.110011] DMAR-IR: x2apic is disabled because BIOS sets x2apic opt
>> out bit.
>> >[0.110012] DMAR-IR: Use 'intremap=no_x2apic_optout' to override the
>> >BIOS setting.
>> >[0.110902] DMAR-IR: Enabled IRQ remapping in xapic mode
>> >[1.687595] DMAR: dmar0: Using Queued invalidation
>> >[1.687608] DMAR: dmar1: Using Queued invalidation
>> >[1.688473] DMAR: Hardware identity mapping for device :ff:08.0
>> >[1.688475] DMAR: Hardware identity mapping for device :ff:08.2
>> >[1.688477] DMAR: Hardware identity mapping for device :ff:08.3
>> >[1.688478] DMAR: Hardware identity mapping for device :ff:09.0
>> >[1.688480] DMAR: Hardware identity mapping for device :ff:09.2
>> >[1.688482] DMAR: Hardware identity mapping for device :ff:09.3
>> >[1.688483] DMAR: Hardware identity mapping for device :ff:0b.0
>> >[1.688485] DMAR: Hardware identity mapping for device :ff:0b.1
>> >[1.688487] DMAR: Hardware identity mapping for device :ff:0b.2
>> >[1.688488] DMAR: Hardware identity mapping for device :ff:0c.0
>> >[1.688490] DMAR: Hardware identity mapping for device :ff:0c.1
>> >[1.688491] DMAR: Hardware identity mapping for device :ff:0c.2
>> >[1.688493] DMAR: Hardware identity mapping for device :ff:0c.3
>> >[1.688494] DMAR: Hardware identity mapping for device :ff:0c.4
>> >[1.688496] DMAR: Hardware identity mapping for device :ff:0c.5
>> >[1.688498] DMAR: Hardware identity mapping for device :ff:0c.6
>> >[1.688499] DMAR: Hardware identity mapping for device :ff:0c.7
>> >[1.688500] DMAR: Hardware identity mapping for device :ff:0d.0
>> >[1.688502] DMAR: Hardware identity mapping for device :ff:0d.1
>> >[1.688504] DMAR: Hardware identity mapping for device :ff:0d.2
>> >[1.688505] DMAR: Hardware identity mapping for device :ff:0d.3
>> >[1.688506] DMAR: Hardware identity mapping for device :ff:0d.4
>> >[1.688508] DMAR: Hardware identity mapping for device :ff:0d.5
>> >[1.688509] DMAR: Hardware identity mapping for device :ff:0d.6
>> >[1.688510] DMAR: Hardware identity mapping for device :ff:0d.7
>> >[1.688511] DMAR: Hardware identity mapping for device :ff:0e.0
>> >[1.688513] DMAR: Hardware identity mapping for device :ff:0e.1
>> >[1.688514] DMAR: Hardware identity mapping for device :ff:0f.0
>> >[1.688516] DMAR: Hardware identity 

Re: [ovs-discuss] Error attaching device to DPDK

[Shivaram Mysore]

I was advised on this mailing list that VFIO drivers are better than
IGB_UIO + more forgiving [1].  Hence switched to the same.

[1] http://dpdk-guide.gitlab.io/dpdk-guide/setup/binding.html

/Shivaram

On Tue, Mar 28, 2017 at 1:12 PM, Bodireddy, Bhanuprakash <
bhanuprakash.bodire...@intel.com> wrote:

>
> >any hints for me based on the info provided?
>
> Your BIOS options and bootcmd line options are appropriate and no issues
> there. I wanted to check if you tried igb_uio drivers
> but saw your post here https://mail.openvswitch.org/
> pipermail/ovs-discuss/2017-March/043993.html, reporting a crash with UIO
> drivers.
>
> Is that the reason why you moved to VFIO? I cross checked your logs but
> found nothing suspicious there.
>
> -Bhanuprakash.
>
> >
> >Thanks
> >
> >On Tue, Mar 28, 2017 at 8:41 AM, Shivaram Mysore
> > wrote:
> >Hi,
> >
> ># dmesg | grep -e DMAR -e IOMMU
> >[0.00] ACPI: DMAR 0x798AF340 000158 (v01 SUPERM SMCI--
> >MB 0001 INTL 20091013)
> >[0.00] DMAR: IOMMU enabled
> >[0.109987] DMAR: Host address width 46
> >[0.109988] DMAR: DRHD base: 0x00fbffc000 flags: 0x0
> >[0.109997] DMAR: dmar0: reg_base_addr fbffc000 ver 1:0 cap
> >d2078c106f0466 ecap f020de
> >[0.109998] DMAR: DRHD base: 0x00c7ffc000 flags: 0x1
> >[0.110002] DMAR: dmar1: reg_base_addr c7ffc000 ver 1:0 cap
> >d2078c106f0466 ecap f020de
> >[0.110003] DMAR: RMRR base: 0x007ba75000 end: 0x007ba84fff
> >[0.110004] DMAR: ATSR flags: 0x0
> >[0.110005] DMAR: RHSA base: 0x00c7ffc000 proximity domain: 0x0
> >[0.110006] DMAR: RHSA base: 0x00fbffc000 proximity domain: 0x1
> >[0.110008] DMAR-IR: IOAPIC id 3 under DRHD base  0xfbffc000 IOMMU 0
> >[0.110008] DMAR-IR: IOAPIC id 1 under DRHD base  0xc7ffc000 IOMMU 1
> >[0.110009] DMAR-IR: IOAPIC id 2 under DRHD base  0xc7ffc000 IOMMU 1
> >[0.110010] DMAR-IR: HPET id 0 under DRHD base 0xc7ffc000
> >[0.110011] DMAR-IR: x2apic is disabled because BIOS sets x2apic opt
> out bit.
> >[0.110012] DMAR-IR: Use 'intremap=no_x2apic_optout' to override the
> >BIOS setting.
> >[0.110902] DMAR-IR: Enabled IRQ remapping in xapic mode
> >[1.687595] DMAR: dmar0: Using Queued invalidation
> >[1.687608] DMAR: dmar1: Using Queued invalidation
> >[1.688473] DMAR: Hardware identity mapping for device :ff:08.0
> >[1.688475] DMAR: Hardware identity mapping for device :ff:08.2
> >[1.688477] DMAR: Hardware identity mapping for device :ff:08.3
> >[1.688478] DMAR: Hardware identity mapping for device :ff:09.0
> >[1.688480] DMAR: Hardware identity mapping for device :ff:09.2
> >[1.688482] DMAR: Hardware identity mapping for device :ff:09.3
> >[1.688483] DMAR: Hardware identity mapping for device :ff:0b.0
> >[1.688485] DMAR: Hardware identity mapping for device :ff:0b.1
> >[1.688487] DMAR: Hardware identity mapping for device :ff:0b.2
> >[1.688488] DMAR: Hardware identity mapping for device :ff:0c.0
> >[1.688490] DMAR: Hardware identity mapping for device :ff:0c.1
> >[1.688491] DMAR: Hardware identity mapping for device :ff:0c.2
> >[1.688493] DMAR: Hardware identity mapping for device :ff:0c.3
> >[1.688494] DMAR: Hardware identity mapping for device :ff:0c.4
> >[1.688496] DMAR: Hardware identity mapping for device :ff:0c.5
> >[1.688498] DMAR: Hardware identity mapping for device :ff:0c.6
> >[1.688499] DMAR: Hardware identity mapping for device :ff:0c.7
> >[1.688500] DMAR: Hardware identity mapping for device :ff:0d.0
> >[1.688502] DMAR: Hardware identity mapping for device :ff:0d.1
> >[1.688504] DMAR: Hardware identity mapping for device :ff:0d.2
> >[1.688505] DMAR: Hardware identity mapping for device :ff:0d.3
> >[1.688506] DMAR: Hardware identity mapping for device :ff:0d.4
> >[1.688508] DMAR: Hardware identity mapping for device :ff:0d.5
> >[1.688509] DMAR: Hardware identity mapping for device :ff:0d.6
> >[1.688510] DMAR: Hardware identity mapping for device :ff:0d.7
> >[1.688511] DMAR: Hardware identity mapping for device :ff:0e.0
> >[1.688513] DMAR: Hardware identity mapping for device :ff:0e.1
> >[1.688514] DMAR: Hardware identity mapping for device :ff:0f.0
> >[1.688516] DMAR: Hardware identity mapping for device :ff:0f.1
> >[1.688517] DMAR: Hardware identity mapping for device :ff:0f.2
> >[1.688518] DMAR: Hardware identity mapping for device :ff:0f.3
> >[1.688520] DMAR: Hardware identity mapping for device :ff:0f.4
> >[1.688521] DMAR: Hardware identity mapping for device :ff:0f.5
> >[1.688523] DMAR: Hardware identity mapping for device :ff:0f.6
> >[1.688524] DMAR: Hardware identity mapping for device :ff:10.0
> >[1.688526] DMAR: Hardware identity mapping for device :ff:10.1
> >[

Re: [ovs-discuss] Error attaching device to DPDK

[Shivaram Mysore]

any hints for me based on the info provided?

Thanks

On Tue, Mar 28, 2017 at 8:41 AM, Shivaram Mysore 
wrote:

> Hi,
>
> # *dmesg | grep -e DMAR -e IOMMU*
> [0.00] ACPI: DMAR 0x798AF340 000158 (v01 SUPERM SMCI--MB
> 0001 INTL 20091013)
> [0.00] DMAR: IOMMU enabled
> [0.109987] DMAR: Host address width 46
> [0.109988] DMAR: DRHD base: 0x00fbffc000 flags: 0x0
> [0.109997] DMAR: dmar0: reg_base_addr fbffc000 ver 1:0 cap
> d2078c106f0466 ecap f020de
> [0.109998] DMAR: DRHD base: 0x00c7ffc000 flags: 0x1
> [0.110002] DMAR: dmar1: reg_base_addr c7ffc000 ver 1:0 cap
> d2078c106f0466 ecap f020de
> [0.110003] DMAR: RMRR base: 0x007ba75000 end: 0x007ba84fff
> [0.110004] DMAR: ATSR flags: 0x0
> [0.110005] DMAR: RHSA base: 0x00c7ffc000 proximity domain: 0x0
> [0.110006] DMAR: RHSA base: 0x00fbffc000 proximity domain: 0x1
> [0.110008] DMAR-IR: IOAPIC id 3 under DRHD base  0xfbffc000 IOMMU 0
> [0.110008] DMAR-IR: IOAPIC id 1 under DRHD base  0xc7ffc000 IOMMU 1
> [0.110009] DMAR-IR: IOAPIC id 2 under DRHD base  0xc7ffc000 IOMMU 1
> [0.110010] DMAR-IR: HPET id 0 under DRHD base 0xc7ffc000
> [0.110011] DMAR-IR: x2apic is disabled because BIOS sets x2apic opt
> out bit.
> [0.110012] DMAR-IR: Use 'intremap=no_x2apic_optout' to override the
> BIOS setting.
> [0.110902] DMAR-IR: Enabled IRQ remapping in xapic mode
> [1.687595] DMAR: dmar0: Using Queued invalidation
> [1.687608] DMAR: dmar1: Using Queued invalidation
> [1.688473] DMAR: Hardware identity mapping for device :ff:08.0
> [1.688475] DMAR: Hardware identity mapping for device :ff:08.2
> [1.688477] DMAR: Hardware identity mapping for device :ff:08.3
> [1.688478] DMAR: Hardware identity mapping for device :ff:09.0
> [1.688480] DMAR: Hardware identity mapping for device :ff:09.2
> [1.688482] DMAR: Hardware identity mapping for device :ff:09.3
> [1.688483] DMAR: Hardware identity mapping for device :ff:0b.0
> [1.688485] DMAR: Hardware identity mapping for device :ff:0b.1
> [1.688487] DMAR: Hardware identity mapping for device :ff:0b.2
> [1.688488] DMAR: Hardware identity mapping for device :ff:0c.0
> [1.688490] DMAR: Hardware identity mapping for device :ff:0c.1
> [1.688491] DMAR: Hardware identity mapping for device :ff:0c.2
> [1.688493] DMAR: Hardware identity mapping for device :ff:0c.3
> [1.688494] DMAR: Hardware identity mapping for device :ff:0c.4
> [1.688496] DMAR: Hardware identity mapping for device :ff:0c.5
> [1.688498] DMAR: Hardware identity mapping for device :ff:0c.6
> [1.688499] DMAR: Hardware identity mapping for device :ff:0c.7
> [1.688500] DMAR: Hardware identity mapping for device :ff:0d.0
> [1.688502] DMAR: Hardware identity mapping for device :ff:0d.1
> [1.688504] DMAR: Hardware identity mapping for device :ff:0d.2
> [1.688505] DMAR: Hardware identity mapping for device :ff:0d.3
> [1.688506] DMAR: Hardware identity mapping for device :ff:0d.4
> [1.688508] DMAR: Hardware identity mapping for device :ff:0d.5
> [1.688509] DMAR: Hardware identity mapping for device :ff:0d.6
> [1.688510] DMAR: Hardware identity mapping for device :ff:0d.7
> [1.688511] DMAR: Hardware identity mapping for device :ff:0e.0
> [1.688513] DMAR: Hardware identity mapping for device :ff:0e.1
> [1.688514] DMAR: Hardware identity mapping for device :ff:0f.0
> [1.688516] DMAR: Hardware identity mapping for device :ff:0f.1
> [1.688517] DMAR: Hardware identity mapping for device :ff:0f.2
> [1.688518] DMAR: Hardware identity mapping for device :ff:0f.3
> [1.688520] DMAR: Hardware identity mapping for device :ff:0f.4
> [1.688521] DMAR: Hardware identity mapping for device :ff:0f.5
> [1.688523] DMAR: Hardware identity mapping for device :ff:0f.6
> [1.688524] DMAR: Hardware identity mapping for device :ff:10.0
> [1.688526] DMAR: Hardware identity mapping for device :ff:10.1
> [1.688527] DMAR: Hardware identity mapping for device :ff:10.5
> [1.688529] DMAR: Hardware identity mapping for device :ff:10.6
> [1.688530] DMAR: Hardware identity mapping for device :ff:10.7
> [1.688532] DMAR: Hardware identity mapping for device :ff:12.0
> [1.688533] DMAR: Hardware identity mapping for device :ff:12.1
> [1.688534] DMAR: Hardware identity mapping for device :ff:12.4
> [1.688536] DMAR: Hardware identity mapping for device :ff:12.5
> [1.688537] DMAR: Hardware identity mapping for device :ff:13.0
> [1.688539] DMAR: Hardware identity mapping for device :ff:13.1
> [1.688541] DMAR: Hardware identity mapping for device :ff:13.2
> [1.688542] DMAR: Hardware identity mapping for device 

Re: [ovs-discuss] Userspace match+action Revalidation

[Joe Stringer]

On 28 March 2017 at 00:05, Advith Nagappa  wrote:
> I am sorry, I should have been more specific.
>
> I meany Userspace ovs without a Kernel module..

Yes, this is what the datapath does.

It doesn't make a difference if using kernel or userspace datapath.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] How to reset counters of ovs-flows ?

[Ben Pfaff]

On Tue, Mar 28, 2017 at 05:26:46PM +0530, f 62 wrote:
> I am trying to reset the counter of ovs-flows. I followed following steps:
> 
> a. ovs-ofctl -O Openflow13 dump-flows br-int > /tmp/br_int
> 
> b. ovs-ofctl -O OpenFlow13 --readd replace-flows br-int /tmp/br_int
> 
> 
>  Its not working . Does it only work if the flow differs in the *file *and
> in the *ovs *? How the counters can be resetted ?

In OpenFlow 1.2 and later, flow_mod messages need to add a special
"reset counts" flag to reset the counters.  ovs-ofctl doesn't currently
provide a way to set that flag.  This is an oversight that should be
corrected.  Until then, if you can use OpenFlow 1.0, then that plus
--readd should allow you to reset the counters.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] Centralizing OVS-DPDK Blogs

[Stokes, Ian]

Hi All,

There are a number of useful blogs maintained by Intel for OVS-DPDK. These 
range from simple 'how-to' articles for specific feature to more technical deep 
dives of how features work under the hood.

Currently these blogs are hosted on the Intel Developer Zone (and will continue 
to be), but there have been suggestions that it could be useful to expose them 
in a more central manner to OVS users.

This could include one or more of the following

1. Expand existing OVS docs with blog content.
2. Adding the blogs to the OVS cookbook.
3. Creating a news feed for OVS using something like the Planet feed reader for 
the OVS webpage. (http://www.planetplanet.org/)

This issue was raised at the OVS-DPDK community meeting and it was decided to 
kick off a community discussion for more input before taking action.

Do people feel centralizing OVS-DPDK content to the OVS project would be useful 
or is the status quo preferred?

For anyone interested in the type of content available I've added the links 
below.

https://software.intel.com/en-us/articles/open-vswitch-with-dpdk-overview
https://software.intel.com/en-us/articles/rate-limiting-configuration-and-usage-for-open-vswitch-with-dpdk
https://software.intel.com/en-us/articles/qos-configuration-and-usage-for-open-vswitch-with-dpdk
https://software.intel.com/en-us/articles/configure-vhost-user-multiqueue-for-ovs-with-dpdk
https://software.intel.com/en-us/articles/vhost-user-numa-awareness-in-open-vswitch-with-dpdk
https://software.intel.com/en-us/articles/dpdk-pdump-in-open-vswitch-with-dpdk
https://01.org/openstack/blogs/stephenfin/2016/enabling-ovs-dpdk-openstack
https://software.intel.com/en-us/articles/jumbo-frames-in-open-vswitch-with-dpdk
https://software.intel.com/en-us/articles/vhost-user-client-mode-in-open-vswitch-with-dpdk
https://software.intel.com/en-us/articles/ovs-dpdk-datapath-classifier
https://software.intel.com/en-us/articles/ovs-dpdk-datapath-classifier-part-2
https://software.intel.com/en-us/articles/link-aggregation-configuration-and-usage-in-open-vswitch-with-dpdk
https://software.intel.com/en-us/articles/analyzing-open-vswitch-with-dpdk-bottlenecks-using-vtune-amplifier
https://software.intel.com/en-us/articles/using-open-vswitch-and-dpdk-with-neutron-in-devstack
https://software.intel.com/en-us/articles/using-open-vswitch-with-dpdk-for-inter-vm-nfv-applications
https://software.intel.com/en-us/articles/using-open-vswitch-with-dpdk-on-ubuntu

Regards
Ian





___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] VM-VM-VM communication via OVS

[Advith Nagappa]

Hello All,

Is it possible to link 2 guest VMS, via another guest VM using OVS bridge?

Is anyone aware of any resource/doc covering this scenario?

Best Regards
Advith Nagappa
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Error attaching device to DPDK

[Bodireddy, Bhanuprakash]

Hello shivaram,

Darrell has already asked if VT-d is enabled?
Your cmdline options are appropriate as you have iommu enabled(intel_iommu=on 
iommu=pt).
can you also check the output of below mentioned command to see if VT-d is 
enabled in BIOS?

$ dmesg | grep -e DMAR -e IOMMU

Regards,
Bhanuprakash.

From: ovs-discuss-boun...@openvswitch.org 
[mailto:ovs-discuss-boun...@openvswitch.org] On Behalf Of Shivaram Mysore
Sent: Tuesday, March 28, 2017 6:25 AM
To: Darrell Ball 
Cc: ovs-discuss@openvswitch.org
Subject: Re: [ovs-discuss] Error attaching device to DPDK

# uname -r
4.10.0-14-generic

# cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.10.0-14-generic root=/dev/mapper/intelsdn--vg-root 
ro quiet intel_iommu=on iommu=pt default_hugepagesz=1G hugepagesz=1G hugepages=4

# uname -a
Linux intelsdn 4.10.0-14-generic #16-Ubuntu SMP Fri Mar 17 15:19:26 UTC 2017 
x86_64 x86_64 x86_64 GNU/Linux

# cat /etc/*release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=17.04
DISTRIB_CODENAME=zesty
DISTRIB_DESCRIPTION="Ubuntu Zesty Zapus (development branch)"
NAME="Ubuntu"
VERSION="17.04 (Zesty Zapus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu Zesty Zapus (development branch)"
VERSION_ID="17.04"


Nothing in the syslog related

On Mon, Mar 27, 2017 at 10:02 PM, Darrell Ball 
> wrote:
I see the pastebins now.

What kernel version are you using ?
VT-d enabled ?
Anything related in syslog ?

From: Shivaram Mysore 
>
Date: Monday, March 27, 2017 at 9:34 PM
To: Darrell Ball >
Cc: "ovs-discuss@openvswitch.org" 
>
Subject: Re: [ovs-discuss] Error attaching device to DPDK

One more datapoint, please check the paste bin log in URL sent earlier.  
Dpdk-devbind works and you can see results in the paste bin log

/Shivaram
::Sent from my mobile device::

On Mar 27, 2017, at 8:34 PM, Darrell Ball 
> wrote:
see inline below

But a few questions:

1)  Are you using the recommended version of dpdk with OVS 2.7 – 16.11 ?

2)  Are you getting a crash still or is this post crash ?

3)  Was the previous crash still happening with 16.11 or only 17.02 ?

Thanks
Darrell

From: 
>
 on behalf of Shivaram Mysore 
>
Date: Monday, March 27, 2017 at 7:45 PM
To: "ovs-discuss@openvswitch.org" 
>
Subject: [ovs-discuss] Error attaching device to DPDK

Hello,

I have installed OVS 2.7 running.  When I do:
1.  # ovs-vsctl add-port ovs-ip64-br0 dpdk-p0 -- set Interface dpdk-p0 
type=dpdk options:dpdk-devargs=:82:00.0
2.  ovs-vsctl: Error detected while setting up 'dpdk-p0': Error attaching 
device ':82:00.0' to DPDK.  See ovs-vswitchd log for details.

Possibly, the port is not bound.
Check using
$DPDK_DIR/tools/dpdk-devbind.py –status
and see the documentation for more detail

and the log file shows:
1.  2017-03-28T02:04:40.004Z|00064|netdev_dpdk|WARN|Error attaching device 
':82:00.0' to DPDK
2.  2017-03-28T02:04:40.004Z|00065|netdev|WARN|dpdk-p0: could not set 
configuration (Invalid argument)

What would cause such a situation?

Commands run: 
https://pastebin.com/0P754x0t
Detailed OVS Log: 
https://pastebin.com/ctBhLuRG

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] Userspace match+action Revalidation

[Advith Nagappa]

I am sorry, I should have been more specific.

I meany Userspace ovs without a Kernel module..

Best Regards
Advith

On Mar 27, 2017 7:57 PM, "Joe Stringer"  wrote:

On 25 March 2017 at 03:05, Advith Nagappa  wrote:
> Hello,
>
>
> Is there a mechanism in OVS which ensures that actions for a particular
rule
> need not be translated each time.

Yes, this is what the datapath does.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss