[ovs-discuss] OVS + DPDK Vhostuser - Failed to set msg fds
Hello All, I am trying to set up a DPDK OVS on KVM.. I am using OVS 2.6.1 and DPDK 16.11.2. The build is successful and I am able to create a OVS bridge and create dpdkvhostuser ports. *ovs-vsctl add-br br0 -- set bridge br0 datapath_type=netdev* *ovs-vsctl add-port br0 vhost-user1 -- set Interface vhost-user1 type=dpdkvhostuser* *ovs-vsctl add-port br0 vhost-user2 -- set Interface vhost-user2 type=dpdkvhostuser* However*, *When I try to set boot up an already created disk via: *qemu-system-x86_64 -m 4096 -hda /home/advith/one.qcow2 -boot c -enable-kvm -no-reboot -net none \* *-chardev socket,id=char1,path=/usr/local/var/run/openvswitch/vhost-user1 \* *-netdev type=vhost-user,id=mynet1,chardev=char1,vhostforce \* *-device virtio-net-pci,mac=00:00:00:00:00:01,netdev=mynet1 \* *-object memory-backend-file,id=mem,size=4096M,mem-path=/dev/hugepages,share=on -numa node,memdev=mem -mem-prealloc* I get a message saying: *qemu-system_x86_64: Failed to set msg fds* *qemu-system_x86_64: vhost v0 0 ring restore failed: -1: Resource temporarily unavailable(11)* *qemu-system_x86_64: Failed to set msg fds* *qemu-system_x86_64: vhost v0 1 ring restore failed: -1: Resource temporarily unavailable(11)* PS: I have two numa nodes, and the dpdk_init parameters I am passing are: *ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-init=true* *ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-socket-mem="1024,1024"* *ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-extra=--vhost-owner libvirt-qemu:kvm --vhost-perm 0666* Has anyone encountered a similar issue? Best Regards Advith Nagappa ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] Questions about IPFIX
I accidentally only responded to you, so here again what I wrote.
Thanks for the quick response! If tested it now but so far I see no
difference. All IPFIX packets have the same flowStartDelta and flowEndDelta.
Furthermore, about the first lines in ipfix_cache_aggregate_entries?
line 1457
to_start = &to_entry->flow_start_timestamp_usec;
to_end = &to_entry->flow_end_timestamp_usec;
from_start = &from_entry->flow_start_timestamp_usec;
from_end = &from_entry->flow_end_timestamp_usec;
if (*to_start > *from_start) {
*to_start = *from_start;
}
if (*to_end < *from_end) {
*to_end = *from_end;
}
Is that not supposed to update the timestamps of the old entry, into
which the new stats are merged?
Regards
Felix
On 06/06/2017 01:16 AM, Greg Rose wrote:
> On 06/02/2017 03:06 PM, Ben Pfaff wrote:
>> On Fri, Jun 02, 2017 at 02:42:49PM -0700, Greg Rose wrote:
>> > On 06/02/2017 09:08 AM, Ben Pfaff wrote:
>> >> ipfix_cache_entry_init() initializes the start and end to be the same:
>> >>
>> >> xgettimeofday(&now);
>> >> entry->flow_end_timestamp_usec = now.tv_usec + 100LL *
>> now.tv_sec;
>> >> entry->flow_start_timestamp_usec =
>> entry->flow_end_timestamp_usec;
>> >>
>> >> and then I don't see anything that ever updates the "end" time. I
>> guess
>> >> that's the issue.
>> >
>> > From looking at the code it appears to me that the
>> ipfix_cache_update() function isn't doing
>> > anything to update the time stamps. It updates the stats but the
>> stats function doesn't update
>> > time stamps. From what I can tell though that seems the place where
>> it should be updated. I can
>> > try whipping up a bug fix patch for this if ipfix_cache_update() is
>> the right place to do the time
>> > stamp update.
>>
>> Seems reasonable.
>>
> I've posted a patch for this here:
>
> https://patchwork.ozlabs.org/patch/771459/
>
> Felix,
>
> can you test it? I'm getting set up to test ipfix but probably won't be
> able to test the patch until tomorrow.
>
> Thanks,
>
> - Greg
--
RWTH Aachen University
Communication and Distributed Systems
http://www.comsys.rwth-aachen.de
smime.p7s
Description: S/MIME Cryptographic Signature
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] meter action for OF1.5
Hi all
I'm trying to contribute meter action for OF1.5 by using the existing patch
"https://patchwork.ozlabs.org/patch/731701/"; in which meter is instruction.
Currently it seems working using ovs-ofctl, but I am not sure if I can pass the
version info as a parameter to the related function, I need a little help from
people who know OvS architecture.
- Volkan
diff --git a/include/openflow/openflow-1.5.h b/include/openflow/openflow-1.5.h
index 3649e6c..d6bdb4f 100644
--- a/include/openflow/openflow-1.5.h
+++ b/include/openflow/openflow-1.5.h
@@ -150,4 +150,99 @@ struct ofp15_group_desc_stats {
};
OFP_ASSERT(sizeof(struct ofp15_group_desc_stats) == 16);
+enum ofp15_instruction_type {
+ OVSINST_OFPIT15_DEPRECATED = 6, /* Deprecated (was apply meter) */
+ OVSINST_OFPIT15_STAT_TRIGGER = 7, /* Statistics triggers */
+ OVSINST_OFPIT15_EXPERIMENTER = 0x /* Experimenter instruction */
+};
+
+enum ofp15_action_type {
+OFPACT15_METER = 6 /* Apply meter (rate limiter) */
+};
+
+/* Action structure for OFPAT_METER */
+struct ofp15_action_meter {
+ovs_be16 type; /* OFPAT_METER */
+ovs_be16 len; /* Length is 8. */
+ovs_be32 meter_id; /* Meter instance. */
+};
+OFP_ASSERT(sizeof(struct ofp15_action_meter) == 8);
+
+/* Statistics for each meter band */
+struct ofp15_meter_band_stats {
+ovs_be64 packet_band_count; /* Number of packets in band. */
+ovs_be64 byte_band_count; /* Number of bytes in band. */
+};
+OFP_ASSERT(sizeof(struct ofp15_meter_band_stats) == 16);
+
+/* Body of reply to OFPMP_METER_STATS request. Meter statistics. */
+struct ofp15_meter_stats {
+ovs_be32 meter_id;/* Meter instance. */
+ovs_be16 len; /* Length in bytes of this stats. */
+uint8_t pad[6];
+ovs_be32 ref_count; /* Number of flows or groups that
+ directly reference this meter. */
+ovs_be64 packet_in_count; /* Number of packets in input. */
+ovs_be64 byte_in_count; /* Number of bytes in input. */
+ovs_be32 duration_sec;/* Time meter has been alive in seconds. */
+ovs_be32 duration_nsec; /* Time meter has been alive in nanoseconds
+ beyond duration_sec. */
+struct ofp15_meter_band_stats band_stats[0]; /* The band_stats length is
inferred
+ from the length field. */
+};
+OFP_ASSERT(sizeof(struct ofp15_meter_stats) == 40);
+
+/* Common header for all meter bands */
+struct ofp15_meter_band_header {
+ovs_be16 type; /* One of OFPMBT_*. */
+ovs_be16 len; /* Length in bytes of this band. */
+ovs_be32 rate; /* Rate for this band. */
+ovs_be32 burst_size; /* Size of bursts. */
+};
+OFP_ASSERT(sizeof(struct ofp15_meter_band_header) == 12);
+
+/* Body of OFPMP15_METER_STATS and OFPMP15_METER_DESC requests. */
+struct ofp15_meter_multipart_request {
+ovs_be32 meter_id; /* Meter instance, or OFPM_ALL. */
+uint8_t pad[4]; /* Align to 64 bits. */
+};
+OFP_ASSERT(sizeof(struct ofp15_meter_multipart_request) == 8);
+
+/* Body of reply to OFPMP_METER_DESC request. Meter configuration. */
+struct ofp15_meter_desc {
+ovs_be16 length; /* Length of this entry. */
+ovs_be16 flags; /* All OFPMF15_* that apply. */
+ovs_be32 meter_id; /* Meter instance. */
+struct ofp15_meter_band_header bands[0]; /* The bands length is
+ inferred from the length field. */
+};
+OFP_ASSERT(sizeof(struct ofp15_meter_desc) == 8);
+
+/* Body of reply to OFPMP_METER_FEATURES request. Meter features. */
+struct ofp15_meter_features {
+ovs_be32 max_meter; /* Maximum number of meters. */
+ovs_be32 band_types; /* Bitmaps of (1 << OFPMBT_*) values supported. */
+ovs_be32 capabilities; /* Bitmaps of "ofp_meter_flags". */
+uint8_t max_bands; /* Maximum bands per meters */
+uint8_t max_color; /* Maximum color value */
+uint8_t pad[2];
+ovs_be32 features; /* Bitmaps of "ofp_meter_feature_flags". */
+uint8_t pad2[4];
+};
+OFP_ASSERT(sizeof(struct ofp15_meter_features) == 24);
+
+/* Meter configuration flags */
+enum ofp15_meter_flags {
+OFPMF15_KBPS = 1 << 0, /* Rate value in kb/s (kilo-bit per second). */
+OFPMF15_PKTPS = 1 << 1, /* Rate value in packet/sec. */
+OFPMF15_BURST = 1 << 2, /* Do burst size. */
+OFPMF15_STATS = 1 << 3, /* Collect statistics. */
+};
+
+/* Meter feature flags */
+enum ofp_meter_feature_flags {
+OFPMFF15_ACTION_SET = 1 << 0, /* Support meter action in action set. */
+OFPMFF15_ANY_POSITION = 1 << 1, /* Support any position in action list. */
+OFPMFF15_MULTI_LIST = 1 << 2, /* Support multiple actions in action list.
*/
+};
#endif /* openflow/openflow-1.5.h */
diff --git a/include/openvswitch/ofp-actions.h
b/include/openvswitch/ofp-actions.h
index 324aac8..a943d46 100644
--- a/include/openvswitch/ofp-actions.h
+++ b/include/openvswitch/ofp-actions.h
@@ -113,6 +113,7 @@ struct vl_mf
Re: [ovs-discuss] Questions about IPFIX
On 06/06/2017 05:18 AM, Felix Konstantin Maurer wrote:
I accidentally only responded to you, so here again what I wrote.
Thanks for the quick response! If tested it now but so far I see no
difference. All IPFIX packets have the same flowStartDelta and flowEndDelta.
Furthermore, about the first lines in ipfix_cache_aggregate_entries?
line 1457
to_start = &to_entry->flow_start_timestamp_usec;
to_end = &to_entry->flow_end_timestamp_usec;
from_start = &from_entry->flow_start_timestamp_usec;
from_end = &from_entry->flow_end_timestamp_usec;
if (*to_start > *from_start) {
*to_start = *from_start;
}
if (*to_end < *from_end) {
*to_end = *from_end;
}
Is that not supposed to update the timestamps of the old entry, into
which the new stats are merged?
Yes, but apparently it's not working right. I'll be setting up an ipfix
configuration today so let me do some further testing/debugging.
Thanks for your help!
- Greg
Regards
Felix
On 06/06/2017 01:16 AM, Greg Rose wrote:
On 06/02/2017 03:06 PM, Ben Pfaff wrote:
On Fri, Jun 02, 2017 at 02:42:49PM -0700, Greg Rose wrote:
On 06/02/2017 09:08 AM, Ben Pfaff wrote:
ipfix_cache_entry_init() initializes the start and end to be the same:
xgettimeofday(&now);
entry->flow_end_timestamp_usec = now.tv_usec + 100LL *
now.tv_sec;
entry->flow_start_timestamp_usec =
entry->flow_end_timestamp_usec;
and then I don't see anything that ever updates the "end" time. I
guess
that's the issue.
From looking at the code it appears to me that the
ipfix_cache_update() function isn't doing
anything to update the time stamps. It updates the stats but the
stats function doesn't update
time stamps. From what I can tell though that seems the place where
it should be updated. I can
try whipping up a bug fix patch for this if ipfix_cache_update() is
the right place to do the time
stamp update.
Seems reasonable.
I've posted a patch for this here:
https://patchwork.ozlabs.org/patch/771459/
Felix,
can you test it? I'm getting set up to test ipfix but probably won't be
able to test the patch until tomorrow.
Thanks,
- Greg
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] OVS + DPDK Vhostuser - Failed to set msg fds
Advith Nagappa writes: > Hello All, > > I am trying to set up a DPDK OVS on KVM.. I am using OVS 2.6.1 and DPDK > 16.11.2. > > The build is successful and I am able to create a OVS bridge and create > dpdkvhostuser ports. > > ovs-vsctl add-br br0 -- set bridge br0 datapath_type=netdev > ovs-vsctl add-port br0 vhost-user1 -- set Interface vhost-user1 > type=dpdkvhostuser > ovs-vsctl add-port br0 vhost-user2 -- set Interface vhost-user2 > type=dpdkvhostuser > > However, When I try to set boot up an already created disk via: > > qemu-system-x86_64 -m 4096 -hda /home/advith/one.qcow2 -boot c -enable-kvm > -no-reboot -net none > \ > -chardev socket,id=char1,path=/usr/local/var/run/openvswitch/vhost-user1 \ > -netdev type=vhost-user,id=mynet1,chardev=char1,vhostforce \ > -device virtio-net-pci,mac=00:00:00:00:00:01,netdev=mynet1 \ > -object > memory-backend-file,id=mem,size=4096M,mem-path=/dev/hugepages,share=on -numa > node,memdev=mem -mem-prealloc > > I get a message saying: > qemu-system_x86_64: Failed to set msg fds > qemu-system_x86_64: vhost v0 0 ring restore failed: -1: Resource temporarily > unavailable > (11) > qemu-system_x86_64: Failed to set msg fds > qemu-system_x86_64: vhost v0 1 ring restore failed: -1: Resource temporarily > unavailable > (11) How many hugepages are allocated? Do you have enough? What's the output of /proc/meminfo > PS: I have two numa nodes, and the dpdk_init parameters I am passing are: > > ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-init=true > ovs-vsctl --no-wait set Open_vSwitch . > other_config:dpdk-socket-mem="1024,1024" > ovs-vsctl --no-wait set Open_vSwitch . other_config:dpdk-extra=--vhost-owner > libvirt-qemu:kvm > --vhost-perm 0666 > > Has anyone encountered a similar issue? > > Best Regards > Advith Nagappa > > ___ > discuss mailing list > disc...@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] meter action for OF1.5
On Tue, Jun 06, 2017 at 12:37:56PM +, Ali Volkan Atli wrote: > I'm trying to contribute meter action for OF1.5 by using the existing > patch "https://patchwork.ozlabs.org/patch/731701/"; in which meter is > instruction. Currently it seems working using ovs-ofctl, but I am not > sure if I can pass the version info as a parameter to the related > function, I need a little help from people who know OvS architecture. "pass the version info as a parameter to the related function"? What function? ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] meter action for OF1.5
ovs_instruction_name_from_type and ofpact_is_apply_actions Meter is instruction for OF1.3 but it is an action-set for OF1.5, so I need to distinguish - Volkan Ben Pfaff wrote On Tue, Jun 06, 2017 at 12:37:56PM +, Ali Volkan Atli wrote: > I'm trying to contribute meter action for OF1.5 by using the existing > patch "https://patchwork.ozlabs.org/patch/731701/"; in which meter is > instruction. Currently it seems working using ovs-ofctl, but I am not > sure if I can pass the version info as a parameter to the related > function, I need a little help from people who know OvS architecture. "pass the version info as a parameter to the related function"? What function? ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] enforce TLSv1.2 in OVN
Hello, We want to ensure that OVN uses only TLSv1.2, but not TLSv1 or TLSv1.1 in our scenario. There are multiple connection, identified to be relevant: - The tunneling data connection between the hypervisors/chassis, like geneve listening on UDP port 6081. - The meta data connections: - The connections to the OVN Southbound DB, which is hosted by ovsdb-server and listening typically TCP port 6642. Connections may be initiated by from the ovn-controllers and ovn-northd. - The connections to the OVN Northbound DB, which is hosted by ovsdb-server and listening typically on TCP port 6641. Connections may be initiated by the Cloud Management System and ovn-northd. Is it correct that encryption is not supported at all for the tunneling data connection? For the meta data connections ovsdb-server acts as the server. ovsdb-server has the command line option --ssl-protocols, but I do not understand how to apply this. ovsdb-server seems to be started by ovn-ctl, but I do not recognize a way to utilize ovn-ctl to pass the --ssl-protocols option. How should the --ssl-protocols option passed to ovsdb-server? Thanks and regards Dominik ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] meter action for OF1.5
I forgot to thank you for working on this. Thanks! ovs_instruction_name_from_type() takes an ovs_instruction_type, so its result should be invariant of the OpenFlow version. ofpact_is_apply_actions() is only used in one place, to encode instructions, so it should be straightforward to update it. But please keep in mind the big picture. OVS tries to keep as much compatibility as it can among the various OpenFlow versions it supports. In this case, I guess this means that if a meter action is added via OpenFlow 1.5, and then dumped in OpenFlow 1.4 or earlier, then it should be translated to a meter instruction if it is in an appropriate position for that, or to an extension action that we would define if it is not. On Tue, Jun 06, 2017 at 03:25:41PM +, Ali Volkan Atli wrote: > ovs_instruction_name_from_type and ofpact_is_apply_actions > > Meter is instruction for OF1.3 but it is an action-set for OF1.5, so I need > to distinguish > > - Volkan > > Ben Pfaff wrote > > On Tue, Jun 06, 2017 at 12:37:56PM +, Ali Volkan Atli wrote: > > I'm trying to contribute meter action for OF1.5 by using the existing > > patch "https://patchwork.ozlabs.org/patch/731701/"; in which meter is > > instruction. Currently it seems working using ovs-ofctl, but I am not > > sure if I can pass the version info as a parameter to the related > > function, I need a little help from people who know OvS architecture. > > "pass the version info as a parameter to the related function"? What > function? ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
Re: [ovs-discuss] enforce TLSv1.2 in OVN
> From: "Dominik Holler" > To: ovs-discuss@openvswitch.org > Cc: "Lance Richardson" , "Numan Siddique" > , "Marcin Mirecki" > , "Dan Kenigsberg" > Sent: Tuesday, 6 June, 2017 11:30:07 AM > Subject: enforce TLSv1.2 in OVN > > Hello, > We want to ensure that OVN uses only TLSv1.2, but not TLSv1 or TLSv1.1 > in our scenario. > > There are multiple connection, identified to be relevant: > > - The tunneling data connection between the hypervisors/chassis, like > geneve listening on UDP port 6081. > > - The meta data connections: > > - The connections to the OVN Southbound DB, which is hosted by >ovsdb-server and listening typically TCP port 6642. Connections >may be initiated by from the ovn-controllers and ovn-northd. > > - The connections to the OVN Northbound DB, which is hosted by >ovsdb-server and listening typically on TCP port 6641. Connections >may be initiated by the Cloud Management System and ovn-northd. > > Is it correct that encryption is not supported at all for the tunneling > data connection? That's correct. There has been some recent work to support the use of IPSec for tunnel encryption, but as far as I know no one has investigated using IPSec with OVN tunnels. If there is a need for this, we could look into it. See: https://patchwork.ozlabs.org/patch/674858/ > > For the meta data connections ovsdb-server acts as the server. > ovsdb-server has the command line option --ssl-protocols, but I do not > understand how to apply this. ovsdb-server seems to be started by > ovn-ctl, but I do not recognize a way to utilize ovn-ctl to > pass the --ssl-protocols option. > How should the --ssl-protocols option passed to ovsdb-server? > I think we'll need to add a new option to ovn-ctl to allow this option to be specified. I also think we should allow the --ssl-protocols configuration to be stored in the ovsdb database and have support in ovn-nbctl/ovn-sbctl etc. for setting it. I'll go ahead and start working on that, it would be good if you could open a BZ for tracking the upstream and backport work. > Thanks and regards > Dominik > > > > > > ___ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
[ovs-discuss] OVS-DPDK - packets received at dpdk interface but not forwarded to VXLAN port
When I work with native OVS (no DPDK) - the traffic is OK.
I see that with native OVS - I have NO VLAN in the outer Ethernet header .
in OVS-DPDK - for some reason - I do have VLAN 2047 - see below ###
> -Original Message-
> From: Avi Cohen (A)
> Sent: Tuesday, 06 June, 2017 1:58 PM
> To: 'dpdk-...@lists.01.org'; 'us...@dpdk.org'
> Subject: OVS-DPDK - packets received at dpdk interface but not
> forwarded to VXLAN port
>
> Hello All (I resend because the prev msg was sent as html)
>
> I have 2 OVS-DPDK installed - with the following below symmetric
> configuration: see ***
>
> When I send ping from a namespace (connected to the ovs-dpdk) - I see
> that the packet is received at the peer via the dpdk interface - BUT
> not sent to the vxlan port
>
> See ### the tcpdump of the packet (captured at the br-phy in the
> peer) - the packet looks OK but not sent to vxlan port for decap.
>
> [note that in the TX direction - the behavior is OK - packet sent from
> namespace to veth0 then to vxlan encap, then to dpdk interface -->
> eventually the packet is received at the dpdk peer interface]
>
> Can someone see any problem with my configuration ?
>
> Best Regards
> avi
>
> ***
> utilities/ovs-vsctl show
> 8cdae740-9eb3-4b79-ad6f-bca0652c5d54
> Bridge br-int
> fail_mode: standalone
> Port "vxlan0"
> Interface "vxlan0"
> type: vxlan
> options: {remote_ip="172.31.100.80"}// the
> peer has other
> ip
> Port "veth0"
> Interface "veth0"
> Port br-int
> Interface br-int
> type: internal
> Bridge br-phy
> fail_mode: standalone
> Port "dpdk0"
> Interface "dpdk0"
> type: dpdk
> options: {dpdk-devargs=":00:03.0"}
> Port br-phy
> Interface br-phy
> type: internal
>
> ###
> 10:27:15.201711 02:d7:d1:26:84:e5 (oui Unknown) > 02:fb:9e:ce:f2:0d
> (oui Unknown), ethertype 802.1Q (0x8100), length 152: vlan 2047, p 0,
> ethertype IPv4, ip-172-31-100-80.eu-central-1.compute.internal.58740 >
> ip-172-31-100-
> 44.eu-central-1.compute.internal.4789: VXLAN, flags [I] (0x08), vni 0
> 7a:fd:3c:4c:ee:d3 (oui Unknown) > d2:ea:96:e1:ef:d2 (oui Unknown),
> ethertype
> IPv4 (0x0800), length 98: 1.1.1.20 > 1.1.1.10: ICMP echo request, id
> 2235, seq 1176, length 64
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
