[ovs-dev] mailto:20190125202328.gu1...@ovn.org
___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH 0/3] revert port duplicate checking optimization
On Thu, Jan 24, 2019 at 12:30:08PM -0200, Flavio Leitner wrote: > On Wed, Jan 23, 2019 at 12:13:25PM -0800, Ben Pfaff wrote: > > I'm not so happy about reverting without having the followup ready. How > > close are we to having the followup? Basically we've got two problems > > here. Without the revert, we have one of them; with the revert, we have > > the other one. I'd rather not trade one for the other, that's not > > ideal. It would be much better to fix both in one shot. > > Hi Ben, > > I guess one is a performance problem and the other is a broken > environment that has no workaround (to my knowledge). I guess you're right. I'm not happy with it, but I reverted this on master, branch-2.11, and branch-2.10. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH net-next 1/1] openvswitch: Declare ovs key structures using macros
On Thu, Jan 24, 2019 at 1:47 AM Eli Britstein wrote:
>
> Declare ovs key structures using macros to enable retrieving fields
> information, with no functional change.
>
I am not sure why is this done. Can you explain what are u trying to solve here?
> Signed-off-by: Eli Britstein
> Reviewed-by: Roi Dayan
> ---
> include/uapi/linux/openvswitch.h | 102
> ++-
> 1 file changed, 69 insertions(+), 33 deletions(-)
>
> diff --git a/include/uapi/linux/openvswitch.h
> b/include/uapi/linux/openvswitch.h
> index dbe0cbe4f1b7..dc8246f871fd 100644
> --- a/include/uapi/linux/openvswitch.h
> +++ b/include/uapi/linux/openvswitch.h
> @@ -387,73 +387,109 @@ enum ovs_frag_type {
>
> #define OVS_FRAG_TYPE_MAX (__OVS_FRAG_TYPE_MAX - 1)
>
> +#define OVS_KEY_FIELD_ARR(type, name, elements) type name[elements];
> +#define OVS_KEY_FIELD(type, name) type name;
> +
> +#define OVS_KEY_ETHERNET_FIELDS \
> +OVS_KEY_FIELD_ARR(__u8, eth_src, ETH_ALEN) \
> +OVS_KEY_FIELD_ARR(__u8, eth_dst, ETH_ALEN)
> +
> struct ovs_key_ethernet {
> - __u8 eth_src[ETH_ALEN];
> - __u8 eth_dst[ETH_ALEN];
> +OVS_KEY_ETHERNET_FIELDS
> };
>
> struct ovs_key_mpls {
> __be32 mpls_lse;
> };
>
> +#define OVS_KEY_IPV4_FIELDS \
> +OVS_KEY_FIELD(__be32, ipv4_src) \
> +OVS_KEY_FIELD(__be32, ipv4_dst) \
> +OVS_KEY_FIELD(__u8, ipv4_proto) \
> +OVS_KEY_FIELD(__u8, ipv4_tos) \
> +OVS_KEY_FIELD(__u8, ipv4_ttl) \
> +OVS_KEY_FIELD(__u8, ipv4_frag /* One of OVS_FRAG_TYPE_*. */)
> +
> struct ovs_key_ipv4 {
> - __be32 ipv4_src;
> - __be32 ipv4_dst;
> - __u8 ipv4_proto;
> - __u8 ipv4_tos;
> - __u8 ipv4_ttl;
> - __u8 ipv4_frag; /* One of OVS_FRAG_TYPE_*. */
> +OVS_KEY_IPV4_FIELDS
> };
>
> +#define OVS_KEY_IPV6_FIELDS \
> +OVS_KEY_FIELD_ARR(__be32, ipv6_src, 4) \
> +OVS_KEY_FIELD_ARR(__be32, ipv6_dst, 4) \
> +OVS_KEY_FIELD(__be32, ipv6_label /* 20-bits in least-significant bits.
> */) \
> +OVS_KEY_FIELD(__u8, ipv6_proto) \
> +OVS_KEY_FIELD(__u8, ipv6_tclass) \
> +OVS_KEY_FIELD(__u8, ipv6_hlimit) \
> +OVS_KEY_FIELD(__u8, ipv6_frag /* One of OVS_FRAG_TYPE_*. */)
> +
> struct ovs_key_ipv6 {
> - __be32 ipv6_src[4];
> - __be32 ipv6_dst[4];
> - __be32 ipv6_label; /* 20-bits in least-significant bits. */
> - __u8 ipv6_proto;
> - __u8 ipv6_tclass;
> - __u8 ipv6_hlimit;
> - __u8 ipv6_frag; /* One of OVS_FRAG_TYPE_*. */
> +OVS_KEY_IPV6_FIELDS
> };
>
> +#define OVS_KEY_TCP_FIELDS \
> +OVS_KEY_FIELD(__be16, tcp_src) \
> +OVS_KEY_FIELD(__be16, tcp_dst)
> +
> struct ovs_key_tcp {
> - __be16 tcp_src;
> - __be16 tcp_dst;
> +OVS_KEY_TCP_FIELDS
> };
>
> +#define OVS_KEY_UDP_FIELDS \
> +OVS_KEY_FIELD(__be16, udp_src) \
> +OVS_KEY_FIELD(__be16, udp_dst)
> +
> struct ovs_key_udp {
> - __be16 udp_src;
> - __be16 udp_dst;
> +OVS_KEY_UDP_FIELDS
> };
>
> +#define OVS_KEY_SCTP_FIELDS \
> +OVS_KEY_FIELD(__be16, sctp_src) \
> +OVS_KEY_FIELD(__be16, sctp_dst)
> +
> struct ovs_key_sctp {
> - __be16 sctp_src;
> - __be16 sctp_dst;
> +OVS_KEY_SCTP_FIELDS
> };
>
> +#define OVS_KEY_ICMP_FIELDS \
> +OVS_KEY_FIELD(__u8, icmp_type) \
> +OVS_KEY_FIELD(__u8, icmp_code)
> +
> struct ovs_key_icmp {
> - __u8 icmp_type;
> - __u8 icmp_code;
> +OVS_KEY_ICMP_FIELDS
> };
>
> +#define OVS_KEY_ICMPV6_FIELDS \
> +OVS_KEY_FIELD(__u8, icmpv6_type) \
> +OVS_KEY_FIELD(__u8, icmpv6_code)
> +
> struct ovs_key_icmpv6 {
> - __u8 icmpv6_type;
> - __u8 icmpv6_code;
> +OVS_KEY_ICMPV6_FIELDS
> };
>
> +#define OVS_KEY_ARP_FIELDS \
> +OVS_KEY_FIELD(__be32, arp_sip) \
> +OVS_KEY_FIELD(__be32, arp_tip) \
> +OVS_KEY_FIELD(__be16, arp_op) \
> +OVS_KEY_FIELD_ARR(__u8, arp_sha, ETH_ALEN) \
> +OVS_KEY_FIELD_ARR(__u8, arp_tha, ETH_ALEN)
> +
> struct ovs_key_arp {
> - __be32 arp_sip;
> - __be32 arp_tip;
> - __be16 arp_op;
> - __u8 arp_sha[ETH_ALEN];
> - __u8 arp_tha[ETH_ALEN];
> +OVS_KEY_ARP_FIELDS
> };
>
> +#define OVS_KEY_ND_FIELDS \
> +OVS_KEY_FIELD_ARR(__be32, nd_target, 4) \
> +OVS_KEY_FIELD_ARR(__u8, nd_sll, ETH_ALEN) \
> +OVS_KEY_FIELD_ARR(__u8, nd_tll, ETH_ALEN)
> +
> struct ovs_key_nd {
> - __be32 nd_target[4];
> - __u8nd_sll[ETH_ALEN];
> - __u8nd_tll[ETH_ALEN];
> +OVS_KEY_ND_FIELDS
> };
>
> +#undef OVS_KEY_FIELD_ARR
> +#undef OVS_KEY_FIELD
> +
> #define OVS_CT_LABELS_LEN_32 4
> #define OVS_CT_LABELS_LEN (OVS_CT_LABELS_LEN_32 * sizeof(__u32))
> struct ovs_key_ct_labels {
> --
> 2.14.4
>
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] treewide: Get rid of // comments, even inside comments.
On Thu, Jan 24, 2019 at 05:00:11PM +0300, Ilya Maximets wrote: > On 23.01.2019 23:09, Ben Pfaff wrote: > > Just a style fix. > > > > With this patch, the following reports no hits: > > > > git ls-files | grep '\.[ch]$' | grep -vE 'datapath|sflow' | xargs grep -n > > // | grep -vE "http|s/|'|\"" > > I'd like this line wrapped. For example, like this: > > git ls-files | grep '\.[ch]$' | grep -vE 'datapath|sflow' \ >| xargs grep -n // | grep -vE "http|s/|'|\"" > > It's still a valid shell command. Thanks, fixed. > Beside that, > Acked-by: Ilya Maximets I applied this to master, thank you! > P.S. sflow_receiver.c is just a bunch of bad style examples. Yes, we imported the sflow_* files without modifying them. The style doesn't match the usual OVS style, for sure. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] flow: fix udp checksum
On Fri, Jan 25, 2019 at 07:08:33PM +0800, Li RongQing wrote: > As per RFC 768, if the calculated UDP checksum is 0, it should be > instead set as 0x in the frame. A value of 0 in the checksum > field indicates to the receiver that no checksum was calculated > and hence it should not verify the checksum. > > Signed-off-by: Li RongQing Thanks, applied to master. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH v1 1/1] hash: Implement hash for aarch64 using CRC32c intrinsics.
On Fri, Jan 25, 2019 at 11:28:01AM +, Yanqin Wei (Arm Technology China) wrote: > This commit adds lib/hash-aarch64.h to implement hash for aarch64. > It is based on aarch64 built-in CRC32c intrinsics, which accelerates > hash function for datapath performance. > > test: > 1. "test-hash" case passed in aarch64 platform. > 2. OVS-DPDK datapth performance test was run(NIC to NIC). > Test bed: aarch64(Centriq 2400) platform. > Test case: DPCLS forwarding(disable EMC + avg 10 subtable lookups) > Test result: improve around 10%. > > Signed-off-by: Yanqin Wei Thanks! This had a little whitespace damage but I repaired it and applied it to master. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] skiplist code
Thanks a lot for the detailed explanation! I borrowed it and sent a patch that removes the member: https://patchwork.ozlabs.org/patch/1031285/ On Fri, Jan 25, 2019 at 07:00:02PM +, Rodriguez Betancourt, Esteban wrote: > Hello, > In this case you are right, the "height" member is not only not used, > it is in fact not required, and can be safely removed, without causing > security issues. > > The code can't read past the end of the 'forward' array because the > skiplist "level" member, that specifies the maximum height of the whole > skiplist. > > The "level" field is updated in insertions and deletions, so that in insertion > the root node will point to the newly created item (if there isn't a list > there > yet). At the deletions, if the deleted item is the last one at that height > then > the root is modified to point to NULL at that height, and the whole skiplist > height is decremented. > > For the forward_to case > - If a node is found in a list of level/height N, then it has height N > (that's why it was inserted in that list) > - forward_to travels throught nodes in the same level, so it is safe, as it > doesn't go up. > - If a node has height N, then it belongs to all the lists initiated at > root->forward[n, n-1 ,n-2, ..., 0] > - forward_to may go to lower levels, but that is safe, because of previous > point. > > So, the protection is given by the "level" field in skiplist root node, and > it is enough > to guarantee that the code won't go off limits at 'forward' array. But yes, > the height > field is unused, unneeded, and can be removed safely. Sorry about the trouble > it may > have caused. > > Regards, > Esteban > > > I'm really suspicious about the code in lib/skiplist.c, because I > > noticed that it writes, but never reads, the 'height' member of struct > > skiplist_node. I suspect that, therefore, in some circumstances the > > code can read past the end of the 'forward' array in skiplist_node. > > > > I'd appreciate it if someone out there has time to verify that I'm right > > or I'm wrong. > > > > Thanks, > > > > Ben. > ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH] skiplist: Remove 'height' from skiplist_node.
This member was write-only: it was initialized and never used later on.
Thanks to Esteban Rodriguez Betancourt for the
following additional rationale:
In this case you are right, the "height" member is not only not
used, it is in fact not required, and can be safely removed,
without causing security issues.
The code can't read past the end of the 'forward' array because
the skiplist "level" member, that specifies the maximum height of
the whole skiplist.
The "level" field is updated in insertions and deletions, so that
in insertion the root node will point to the newly created item
(if there isn't a list there yet). At the deletions, if the
deleted item is the last one at that height then the root is
modified to point to NULL at that height, and the whole skiplist
height is decremented.
For the forward_to case:
- If a node is found in a list of level/height N, then it has
height N (that's why it was inserted in that list)
- forward_to travels throught nodes in the same level, so it is
safe, as it doesn't go up.
- If a node has height N, then it belongs to all the lists
initiated at root->forward[n, n-1 ,n-2, ..., 0]
- forward_to may go to lower levels, but that is safe, because of
previous point.
So, the protection is given by the "level" field in skiplist root
node, and it is enough to guarantee that the code won't go off
limits at 'forward' array. But yes, the height field is unused,
unneeded, and can be removed safely.
CC: Esteban Rodriguez Betancourt
Signed-off-by: Ben Pfaff
---
lib/skiplist.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/lib/skiplist.c b/lib/skiplist.c
index 2cea6d8dfbee..1ae592623099 100644
--- a/lib/skiplist.c
+++ b/lib/skiplist.c
@@ -40,7 +40,6 @@
/* Skiplist node container */
struct skiplist_node {
const void *data; /* Pointer to saved data. */
-int height; /* Height of this node. */
struct skiplist_node *forward[]; /* Links to the next nodes. */
};
@@ -66,7 +65,6 @@ skiplist_create_node(int level, const void *object)
new_node = xmalloc(alloc_size);
new_node->data = object;
-new_node->height = level;
memset(new_node->forward, 0,
(level + 1) * sizeof new_node->forward[0]);
--
2.20.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH v5] Monitor Database table to manage lifecycle of IDL client.
The Python IDL implementation supports ovsdb cluster connections. This patch is a follow up to commit 31e434fc98, it adds the option of connecting to the leader (the default) in the Raft-based cluster. It mimics the exisiting C IDL support for clusters introduced in commit 1b1d2e6daa. The _Server database schema is first requested, then a monitor of the Database table in the _Server Database. Method __check_server_db verifies the eligibility of the server. If the attempt to obtain a monitor of the _Server database fails and a cluster id was not provided this implementation proceeds to request the data monitor. If a cluster id was provided via the set_cluster_id method then the connection is aborted and a connection to a different node is instead attempted, until a valid cluster node is found. Thus, when supplied, cluster id is interpreted as the intention to only allow connections to a clustered database. If not supplied, connections to standalone nodes, or nodes that do not have the _Server database are allowed. change_seqno is not incremented in the case of Database table updates. Signed-off-by: Ted Elhourani --- v4 -> v5 * Increase test timeout. * Spell out list of files to cat for shell compatibility. v3 -> v4 * export -f is not compatible with FreeBSD, modify tests to avoid shell function export. * Re-add a line that was removed by mistake. v2 -> v3 * Add 2 tests, treat cluster_id as a string, mv arg till end, pep8 fixes. v1 -> v2 * Modify for backward compatibility with _Server-less ovsdb servers. python/ovs/db/idl.py| 219 python/ovs/reconnect.py | 3 + tests/ovsdb-idl.at | 129 +--- tests/test-ovsdb.py | 67 ++- 4 files changed, 372 insertions(+), 46 deletions(-) diff --git a/python/ovs/db/idl.py b/python/ovs/db/idl.py index 250e897..84af978 100644 --- a/python/ovs/db/idl.py +++ b/python/ovs/db/idl.py @@ -38,6 +38,8 @@ ROW_DELETE = "delete" OVSDB_UPDATE = 0 OVSDB_UPDATE2 = 1 +CLUSTERED = "clustered" + class Idl(object): """Open vSwitch Database Interface Definition Language (OVSDB IDL). @@ -92,10 +94,13 @@ class Idl(object): """ IDL_S_INITIAL = 0 -IDL_S_MONITOR_REQUESTED = 1 -IDL_S_MONITOR_COND_REQUESTED = 2 +IDL_S_SERVER_SCHEMA_REQUESTED = 1 +IDL_S_SERVER_MONITOR_REQUESTED = 2 +IDL_S_DATA_MONITOR_REQUESTED = 3 +IDL_S_DATA_MONITOR_COND_REQUESTED = 4 -def __init__(self, remote, schema_helper, probe_interval=None): +def __init__(self, remote, schema_helper, probe_interval=None, + leader_only=True): """Creates and returns a connection to the database named 'db_name' on 'remote', which should be in a form acceptable to ovs.jsonrpc.session.open(). The connection will maintain an in-memory @@ -119,6 +124,9 @@ class Idl(object): The IDL uses and modifies 'schema' directly. +If 'leader_only' is set to True (default value) the IDL will only +monitor and transact with the leader of the cluster. + If "probe_interval" is zero it disables the connection keepalive feature. If non-zero the value will be forced to at least 1000 milliseconds. If None it will just use the default value in OVS. @@ -137,6 +145,20 @@ class Idl(object): self._last_seqno = None self.change_seqno = 0 self.uuid = uuid.uuid1() + +# Server monitor. +self._server_schema_request_id = None +self._server_monitor_request_id = None +self._db_change_aware_request_id = None +self._server_db_name = '_Server' +self._server_db_table = 'Database' +self.server_tables = None +self._server_db = None +self.server_monitor_uuid = uuid.uuid1() +self.leader_only = leader_only +self.cluster_id = None +self._min_index = 0 + self.state = self.IDL_S_INITIAL # Database locking. @@ -172,6 +194,12 @@ class Idl(object): remotes.append(r) return remotes +def set_cluster_id(self, cluster_id): +"""Set the id of the cluster that this idl must connect to.""" +self.cluster_id = cluster_id +if self.state != self.IDL_S_INITIAL: +self.force_reconnect() + def index_create(self, table, name): """Create a named multi-column index on a table""" return self.tables[table].rows.index_create(name) @@ -222,7 +250,7 @@ class Idl(object): if seqno != self._last_seqno: self._last_seqno = seqno self.__txn_abort_all() -self.__send_monitor_request() +self.__send_server_schema_request() if self.lock_name: self.__send_lock_request() break @@ -230,6 +258,7 @@ class Idl(object): msg = self._session.recv() if msg is
Re: [ovs-dev] [PATCH] ovs-macros.at: Better hide 'exec -a' checking.
On Fri, Jan 25, 2019 at 04:21:22PM +0300, Ilya Maximets wrote: > There is some issue with parsing of redirection options > on some shells. For example: > > $ (exec -a name true) 2>&1 >/dev/null || echo "failed" > sh: 10: exec: -a: not found > failed > > $ (exec -a name true) >/dev/null 2>&1 || echo "failed" > failed > > So, the order of redirections matters for some reason. > Let's replace our current version with simple redirection of stderr. > This version seems to work in most of shells except [t]csh. But it's > really tricky to write portable redirections that works with csh and > this shell will not be used by the testsuite on most of the systems. > > With the new version: > > # cat test.sh > ((exec -a myname true 2>/dev/null) && echo "OK") || echo "fail" > > # sh ./test.sh > fail > # bash ./test.sh > OK > # tcsh ./test.sh > -a: Command not found. > fail > > Signed-off-by: Ilya Maximets Thanks for the fix. I applied this to master. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] suspicious skiplist code
Hello, In this case you are right, the "height" member is not only not used, it is in fact not required, and can be safely removed, without causing security issues. The code can't read past the end of the 'forward' array because the skiplist "level" member, that specifies the maximum height of the whole skiplist. The "level" field is updated in insertions and deletions, so that in insertion the root node will point to the newly created item (if there isn't a list there yet). At the deletions, if the deleted item is the last one at that height then the root is modified to point to NULL at that height, and the whole skiplist height is decremented. For the forward_to case - If a node is found in a list of level/height N, then it has height N (that's why it was inserted in that list) - forward_to travels throught nodes in the same level, so it is safe, as it doesn't go up. - If a node has height N, then it belongs to all the lists initiated at root->forward[n, n-1 ,n-2, ..., 0] - forward_to may go to lower levels, but that is safe, because of previous point. So, the protection is given by the "level" field in skiplist root node, and it is enough to guarantee that the code won't go off limits at 'forward' array. But yes, the height field is unused, unneeded, and can be removed safely. Sorry about the trouble it may have caused. Regards, Esteban > I'm really suspicious about the code in lib/skiplist.c, because I > noticed that it writes, but never reads, the 'height' member of struct > skiplist_node. I suspect that, therefore, in some circumstances the > code can read past the end of the 'forward' array in skiplist_node. > > I'd appreciate it if someone out there has time to verify that I'm right > or I'm wrong. > > Thanks, > > Ben. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] dpdk: Limit DPDK memory usage.
On Fri, Jan 25, 2019 at 04:08:10PM +0300, Ilya Maximets wrote: > On 23.01.2019 15:40, Aaron Conole wrote: > > Ilya Maximets writes: > > > >> Aaron, what do you think about supporting tags like 'Based-on' in ovsrobot > >> ? > >> For example, patchew in QEMU parses 'Based-on: ' tags. > >> Maybe we can use patchwork ids or something similar. > > > > I think there's a way to do it without a tag in the commit message. I > > don't like having a tag for this sort of information in the commit > > message itself since it isn't useful to preserve in the commit history > > (and can serve to clutter things up). > > I don't like the idea having such tags in git log too. But we could place > them under the cut line like in this patch. But, yes, developers will > frequently misplace them in the main part of commit-message. OTOH, we could > add a quick checkpatch rule for that. > > > > > Currently, we use [PATCH branch-XXX] to imply that the series needs to > > be based on a specific branch. The ovsrobot automatically creates > > branches based on patch series. Maybe it makes sense to enhance that so > > that some subject metadata marker (series-[0-9]+) would automatically > > check out the series and then apply the patches. This also lets a > > reviewer know at a glance that the patches are destined to be applied > > after a specific series which is already posted. One downside is that > > it's more subject line data. I can't think of others at the moment, but > > I'm sure there are some. Since the robot doesn't currently clean up > > branches, it's entirely possible to even base a series on a severely old > > branch (so that should get fixed at some point). > > > > WDYT? > > Long subject lines is not a very good thing too. They hiding the patch > subject in the mess of tags. > Not sure what is better. > > Ben, do you have any thoughts about this? I'm not a big fan of patch series that have prerequisite patches. Is there a common, good reason for them? I usually encourage people to post self-contained series. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] ¿Cómo prevenir la morosidad?
Cursos escenciales - Webinar Interactivo – Jueves 21 de Febrero Recuperación de cartera vencida Este webinar interactivo está diseñado para brindar a las empresas estrategias y técnicas para desarrollar mejores procedimientos de recuperación de cartera dentro del marco legar pertinente y en una relación de ganar- ganar con los clientes. Aprenderemos a manejar una cartera exitosa, recuperar el dinero y obtener ganancias. Objetivos Específicos: • El participante aprenderá a controlar su cartera vencida con ciertas medidas de cobranza que le permitirán suspender. • El participante podrá analizar el historial crediticio del cliente. • El participante mantendrá a sus finanzas organizadas. Para mayor información, responder sobre este correo con la palabra Cartera + los siguientes datos: NOMBRE: TELÉFONO: EMPRESA: Llamanos al (045) 55 1554 6630 www.Innovalearn.mx ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] Principales tipos de Auditoría Interna.
Cursos escenciales - Webinar Interactivo – Miércoles 20 de Febrero Guía de Auditoría y Control Interno para Detectar Fraudes Nuestro webinar funciona como una guía para que el participante revise los conceptos clave del Control Interno y la Auditoría para la prevención de escenarios que conlleven malas prácticas sobre estructuras organizacionales de cualquier tamaño y reconozca la documentación necesaria así como los procedimientos y procesos para implementar las mejores prácticas corporativas. Perfeccionar, actualizar y mejorar el proceso en que la Auditoría Interna se lleva a cabo para detección oportuna de fraudes. OBJETIVOS ESPECÍFICOS: • El participante repasará los conceptos básicos de Auditoría y Control Interno. • El participante revisará los requerimientos éticos del Auditor Interno y los principales tipos de Auditoría Interna. • El participante estudiará los procesos y procedimientos de Auditoría Interna. • El participante revisará el concepto de fraude y su responsabilidad ante el descubrimiento del mismo. Para mayor información, responder sobre este correo con la palabra Fraudes + los siguientes datos: NOMBRE: TELÉFONO: EMPRESA: Llamanos al (045) 55 1554 6630 www.Innovalearn.mx ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] acinclude: Also use LIBS from dpkg pkg-config
Luca Boccassi writes: > On Fri, 2019-01-25 at 16:39 +, Luca Boccassi wrote: >> On Fri, 2019-01-25 at 11:28 -0500, Aaron Conole wrote: >> > Christian Ehrhardt writes: >> > >> > > DPDK 18.11 builds using the more modern meson build system no >> > > more >> > > provide the -ldpdk linker script. Instead it is expected to use >> > > pkgconfig for linker options as well. >> > > >> > > This change will set DPDK_LIB from pkg-config (if pkg-config was >> > > available) and since that already carries the whole-archive flags >> > > around >> > > the PMDs skips the further wrapping in more whole-archive if that >> > > is >> > > already part of DPDK_LIB. >> > > >> > > Signed-off-by: Christian Ehrhardt > > > om >> > > > >> > > >> > > --- >> > > acinclude.m4 | 17 - >> > > 1 file changed, 12 insertions(+), 5 deletions(-) >> > > >> > > diff --git a/acinclude.m4 b/acinclude.m4 >> > > index f038fd457..a45411860 100644 >> > > --- a/acinclude.m4 >> > > +++ b/acinclude.m4 >> > > @@ -223,9 +223,9 @@ AC_DEFUN([OVS_CHECK_DPDK], [ >> > > case "$with_dpdk" in >> > > yes) >> > > DPDK_AUTO_DISCOVER="true" >> > > -PKG_CHECK_MODULES([DPDK], [libdpdk], >> > > - [DPDK_INCLUDE="$DPDK_CFLAGS"], >> > > - [DPDK_INCLUDE="- >> > > I/usr/local/include/dpdk >> > > -I/usr/include/dpdk"]) >> > > +PKG_CHECK_MODULES_STATIC([DPDK], [libdpdk], >> > > + [DPDK_INCLUDE="$DPDK_CFLAGS", >> > > DPDK_LIB="$DPDK_LIBS"], >> > > + >> > > [DPDK_INCLUDE="-I/usr/local/include/dpdk -I/usr/include/dpdk", >> > > DPDK_LIB="-ldpdk"]) >> > >> > Something about this autoconf check caused all of the travis builds >> > to >> > fail: >> > >> > https://travis-ci.org/ovsrobot/ovs/builds/483986081 >> > >> > The PKG_CHECK_MODULES_STATIC seems to have been added in a later >> > version >> > of autoconf than is shipped in the travis environment, so it might >> > be >> > something we need to test against and provide an alternative >> > implementation, ala the following bug report: >> > >> > https://bugs.freedesktop.org/show_bug.cgi?id=19541 >> >> Hi, >> >> The PKG_CHECK* macros come from the pkg-config package, not autoconf, >> in version 0.29. The version of pkg-config in Ubuntu 14.04 does not >> indeed contain it, but 16.04 does. >> >> If you go down the reimplementation route, I would recommend checking >> for the macro version first and add a comment, so that you can then >> drop it when compatibility with Ubuntu 14.04 and Debian 8 is no >> longer >> required. > > Also, these macro files are all versioned - autoconf is smart enough to > check the version if you have it locally, and if the system's is > higher, it will use that one instead, so there's no drawback to > backporting. Cool, I didn't know that! > In other words, you can drop pkg.m4 version 0.29 in the m4/ directory > in the repository, add "m4_include([m4/pkg.m4])" to configure.ac and > then not worry about it anymore until compatibility with Ubuntu 14.04 > and Debian 8 can be dropped. That sounds like a solution. >> > Thinking about it, is there a reason to change from dynamic linking >> > to >> > static linking? Especially since we can achieve something similar >> > via >> > the `PKG_CONFIG="$PKG_CONFIG --static"` override? >> >> Note that this is not doing static linking - it's just getting the >> full >> list of libs (which includes all the PMDs). The _STATIC macro is >> implemented exactly as you suggested above. >> ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] acinclude: Also use LIBS from dpkg pkg-config
On Fri, Jan 25, 2019 at 04:39:15PM +, Luca Boccassi wrote: > On Fri, 2019-01-25 at 11:28 -0500, Aaron Conole wrote: > > Christian Ehrhardt writes: > > > > > DPDK 18.11 builds using the more modern meson build system no more > > > provide the -ldpdk linker script. Instead it is expected to use > > > pkgconfig for linker options as well. > > > > > > This change will set DPDK_LIB from pkg-config (if pkg-config was > > > available) and since that already carries the whole-archive flags > > > around > > > the PMDs skips the further wrapping in more whole-archive if that > > > is > > > already part of DPDK_LIB. > > > > > > Signed-off-by: Christian Ehrhardt > > > > > > --- > > > acinclude.m4 | 17 - > > > 1 file changed, 12 insertions(+), 5 deletions(-) > > > > > > diff --git a/acinclude.m4 b/acinclude.m4 > > > index f038fd457..a45411860 100644 > > > --- a/acinclude.m4 > > > +++ b/acinclude.m4 > > > @@ -223,9 +223,9 @@ AC_DEFUN([OVS_CHECK_DPDK], [ > > > case "$with_dpdk" in > > > yes) > > > DPDK_AUTO_DISCOVER="true" > > > -PKG_CHECK_MODULES([DPDK], [libdpdk], > > > - [DPDK_INCLUDE="$DPDK_CFLAGS"], > > > - [DPDK_INCLUDE="-I/usr/local/include/dpdk > > > -I/usr/include/dpdk"]) > > > +PKG_CHECK_MODULES_STATIC([DPDK], [libdpdk], > > > + [DPDK_INCLUDE="$DPDK_CFLAGS", > > > DPDK_LIB="$DPDK_LIBS"], > > > + > > > [DPDK_INCLUDE="-I/usr/local/include/dpdk -I/usr/include/dpdk", > > > DPDK_LIB="-ldpdk"]) > > > > Something about this autoconf check caused all of the travis builds > > to > > fail: > > > > https://travis-ci.org/ovsrobot/ovs/builds/483986081 > > > > The PKG_CHECK_MODULES_STATIC seems to have been added in a later > > version > > of autoconf than is shipped in the travis environment, so it might be > > something we need to test against and provide an alternative > > implementation, ala the following bug report: > > > > https://bugs.freedesktop.org/show_bug.cgi?id=19541 > > Hi, > > The PKG_CHECK* macros come from the pkg-config package, not autoconf, > in version 0.29. The version of pkg-config in Ubuntu 14.04 does not > indeed contain it, but 16.04 does. Probably one can just copy pkg.m4 from pkg-config into the OVS m4/ directory. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] acinclude: Also use LIBS from dpkg pkg-config
On Fri, 2019-01-25 at 16:39 +, Luca Boccassi wrote: > On Fri, 2019-01-25 at 11:28 -0500, Aaron Conole wrote: > > Christian Ehrhardt writes: > > > > > DPDK 18.11 builds using the more modern meson build system no > > > more > > > provide the -ldpdk linker script. Instead it is expected to use > > > pkgconfig for linker options as well. > > > > > > This change will set DPDK_LIB from pkg-config (if pkg-config was > > > available) and since that already carries the whole-archive flags > > > around > > > the PMDs skips the further wrapping in more whole-archive if that > > > is > > > already part of DPDK_LIB. > > > > > > Signed-off-by: Christian Ehrhardt > > om > > > > > > > > > > --- > > > acinclude.m4 | 17 - > > > 1 file changed, 12 insertions(+), 5 deletions(-) > > > > > > diff --git a/acinclude.m4 b/acinclude.m4 > > > index f038fd457..a45411860 100644 > > > --- a/acinclude.m4 > > > +++ b/acinclude.m4 > > > @@ -223,9 +223,9 @@ AC_DEFUN([OVS_CHECK_DPDK], [ > > > case "$with_dpdk" in > > > yes) > > > DPDK_AUTO_DISCOVER="true" > > > -PKG_CHECK_MODULES([DPDK], [libdpdk], > > > - [DPDK_INCLUDE="$DPDK_CFLAGS"], > > > - [DPDK_INCLUDE="- > > > I/usr/local/include/dpdk > > > -I/usr/include/dpdk"]) > > > +PKG_CHECK_MODULES_STATIC([DPDK], [libdpdk], > > > + [DPDK_INCLUDE="$DPDK_CFLAGS", > > > DPDK_LIB="$DPDK_LIBS"], > > > + > > > [DPDK_INCLUDE="-I/usr/local/include/dpdk -I/usr/include/dpdk", > > > DPDK_LIB="-ldpdk"]) > > > > Something about this autoconf check caused all of the travis builds > > to > > fail: > > > > https://travis-ci.org/ovsrobot/ovs/builds/483986081 > > > > The PKG_CHECK_MODULES_STATIC seems to have been added in a later > > version > > of autoconf than is shipped in the travis environment, so it might > > be > > something we need to test against and provide an alternative > > implementation, ala the following bug report: > > > > https://bugs.freedesktop.org/show_bug.cgi?id=19541 > > Hi, > > The PKG_CHECK* macros come from the pkg-config package, not autoconf, > in version 0.29. The version of pkg-config in Ubuntu 14.04 does not > indeed contain it, but 16.04 does. > > If you go down the reimplementation route, I would recommend checking > for the macro version first and add a comment, so that you can then > drop it when compatibility with Ubuntu 14.04 and Debian 8 is no > longer > required. Also, these macro files are all versioned - autoconf is smart enough to check the version if you have it locally, and if the system's is higher, it will use that one instead, so there's no drawback to backporting. In other words, you can drop pkg.m4 version 0.29 in the m4/ directory in the repository, add "m4_include([m4/pkg.m4])" to configure.ac and then not worry about it anymore until compatibility with Ubuntu 14.04 and Debian 8 can be dropped. > > Thinking about it, is there a reason to change from dynamic linking > > to > > static linking? Especially since we can achieve something similar > > via > > the `PKG_CONFIG="$PKG_CONFIG --static"` override? > > Note that this is not doing static linking - it's just getting the > full > list of libs (which includes all the PMDs). The _STATIC macro is > implemented exactly as you suggested above. > -- Kind regards, Luca Boccassi___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] acinclude: Also use LIBS from dpkg pkg-config
On Fri, 2019-01-25 at 11:28 -0500, Aaron Conole wrote: > Christian Ehrhardt writes: > > > DPDK 18.11 builds using the more modern meson build system no more > > provide the -ldpdk linker script. Instead it is expected to use > > pkgconfig for linker options as well. > > > > This change will set DPDK_LIB from pkg-config (if pkg-config was > > available) and since that already carries the whole-archive flags > > around > > the PMDs skips the further wrapping in more whole-archive if that > > is > > already part of DPDK_LIB. > > > > Signed-off-by: Christian Ehrhardt > > > > --- > > acinclude.m4 | 17 - > > 1 file changed, 12 insertions(+), 5 deletions(-) > > > > diff --git a/acinclude.m4 b/acinclude.m4 > > index f038fd457..a45411860 100644 > > --- a/acinclude.m4 > > +++ b/acinclude.m4 > > @@ -223,9 +223,9 @@ AC_DEFUN([OVS_CHECK_DPDK], [ > > case "$with_dpdk" in > > yes) > > DPDK_AUTO_DISCOVER="true" > > -PKG_CHECK_MODULES([DPDK], [libdpdk], > > - [DPDK_INCLUDE="$DPDK_CFLAGS"], > > - [DPDK_INCLUDE="-I/usr/local/include/dpdk > > -I/usr/include/dpdk"]) > > +PKG_CHECK_MODULES_STATIC([DPDK], [libdpdk], > > + [DPDK_INCLUDE="$DPDK_CFLAGS", > > DPDK_LIB="$DPDK_LIBS"], > > + > > [DPDK_INCLUDE="-I/usr/local/include/dpdk -I/usr/include/dpdk", > > DPDK_LIB="-ldpdk"]) > > Something about this autoconf check caused all of the travis builds > to > fail: > > https://travis-ci.org/ovsrobot/ovs/builds/483986081 > > The PKG_CHECK_MODULES_STATIC seems to have been added in a later > version > of autoconf than is shipped in the travis environment, so it might be > something we need to test against and provide an alternative > implementation, ala the following bug report: > > https://bugs.freedesktop.org/show_bug.cgi?id=19541 Hi, The PKG_CHECK* macros come from the pkg-config package, not autoconf, in version 0.29. The version of pkg-config in Ubuntu 14.04 does not indeed contain it, but 16.04 does. If you go down the reimplementation route, I would recommend checking for the macro version first and add a comment, so that you can then drop it when compatibility with Ubuntu 14.04 and Debian 8 is no longer required. > Thinking about it, is there a reason to change from dynamic linking > to > static linking? Especially since we can achieve something similar > via > the `PKG_CONFIG="$PKG_CONFIG --static"` override? Note that this is not doing static linking - it's just getting the full list of libs (which includes all the PMDs). The _STATIC macro is implemented exactly as you suggested above. -- Kind regards, Luca Boccassi___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] acinclude: Also use LIBS from dpkg pkg-config
Christian Ehrhardt writes: > DPDK 18.11 builds using the more modern meson build system no more > provide the -ldpdk linker script. Instead it is expected to use > pkgconfig for linker options as well. > > This change will set DPDK_LIB from pkg-config (if pkg-config was > available) and since that already carries the whole-archive flags around > the PMDs skips the further wrapping in more whole-archive if that is > already part of DPDK_LIB. > > Signed-off-by: Christian Ehrhardt > --- > acinclude.m4 | 17 - > 1 file changed, 12 insertions(+), 5 deletions(-) > > diff --git a/acinclude.m4 b/acinclude.m4 > index f038fd457..a45411860 100644 > --- a/acinclude.m4 > +++ b/acinclude.m4 > @@ -223,9 +223,9 @@ AC_DEFUN([OVS_CHECK_DPDK], [ > case "$with_dpdk" in >yes) > DPDK_AUTO_DISCOVER="true" > -PKG_CHECK_MODULES([DPDK], [libdpdk], > - [DPDK_INCLUDE="$DPDK_CFLAGS"], > - [DPDK_INCLUDE="-I/usr/local/include/dpdk > -I/usr/include/dpdk"]) > +PKG_CHECK_MODULES_STATIC([DPDK], [libdpdk], > + [DPDK_INCLUDE="$DPDK_CFLAGS", > DPDK_LIB="$DPDK_LIBS"], > + > [DPDK_INCLUDE="-I/usr/local/include/dpdk -I/usr/include/dpdk", > DPDK_LIB="-ldpdk"]) Something about this autoconf check caused all of the travis builds to fail: https://travis-ci.org/ovsrobot/ovs/builds/483986081 The PKG_CHECK_MODULES_STATIC seems to have been added in a later version of autoconf than is shipped in the travis environment, so it might be something we need to test against and provide an alternative implementation, ala the following bug report: https://bugs.freedesktop.org/show_bug.cgi?id=19541 Thinking about it, is there a reason to change from dynamic linking to static linking? Especially since we can achieve something similar via the `PKG_CONFIG="$PKG_CONFIG --static"` override? > ;; >*) > DPDK_AUTO_DISCOVER="false" > @@ -238,10 +238,10 @@ AC_DEFUN([OVS_CHECK_DPDK], [ > DPDK_INCLUDE="-I$DPDK_INCLUDE_PATH/dpdk" > fi > DPDK_LIB_DIR="$with_dpdk/lib" > +DPDK_LIB="-ldpdk" > ;; > esac > > -DPDK_LIB="-ldpdk" > DPDK_EXTRA_LIB="" > > ovs_save_CFLAGS="$CFLAGS" > @@ -346,7 +346,14 @@ AC_DEFUN([OVS_CHECK_DPDK], [ > # > # These options are specified inside a single -Wl directive to prevent > # autotools from reordering them. > -DPDK_vswitchd_LDFLAGS=-Wl,--whole-archive,$DPDK_LIB,--no-whole-archive > +# > +# OTOH newer versions of dpdk pkg-config (generated with Meson) > +# will already have flagged just the right set of libs with > +# --whole-archive - in those cases do not wrap it once more. > +case "$DPDK_LIB" in > + *whole-archive*) DPDK_vswitchd_LDFLAGS=$DPDK_LIB;; > + *) > DPDK_vswitchd_LDFLAGS=-Wl,--whole-archive,$DPDK_LIB,--no-whole-archive > +esac > AC_SUBST([DPDK_vswitchd_LDFLAGS]) > AC_DEFINE([DPDK_NETDEV], [1], [System uses the DPDK module.]) >fi ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH] ovs-macros.at: Better hide 'exec -a' checking.
There is some issue with parsing of redirection options
on some shells. For example:
$ (exec -a name true) 2>&1 >/dev/null || echo "failed"
sh: 10: exec: -a: not found
failed
$ (exec -a name true) >/dev/null 2>&1 || echo "failed"
failed
So, the order of redirections matters for some reason.
Let's replace our current version with simple redirection of stderr.
This version seems to work in most of shells except [t]csh. But it's
really tricky to write portable redirections that works with csh and
this shell will not be used by the testsuite on most of the systems.
With the new version:
# cat test.sh
((exec -a myname true 2>/dev/null) && echo "OK") || echo "fail"
# sh ./test.sh
fail
# bash ./test.sh
OK
# tcsh ./test.sh
-a: Command not found.
fail
Signed-off-by: Ilya Maximets
---
tests/ovs-macros.at | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/ovs-macros.at b/tests/ovs-macros.at
index 4a21f72b2..10593429d 100644
--- a/tests/ovs-macros.at
+++ b/tests/ovs-macros.at
@@ -173,7 +173,7 @@ uuidfilt () {
# prints a message if a bunch of identical processes are running.
#
# Not all shells support "exec -a NAME", so test for it.
-if (exec -a myname true 2>&1 >/dev/null); then
+if (exec -a myname true 2>/dev/null); then
run_as () {
(exec -a "$@")
}
--
2.17.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] dpdk: Limit DPDK memory usage.
On 23.01.2019 15:40, Aaron Conole wrote: > Ilya Maximets writes: > >> Aaron, what do you think about supporting tags like 'Based-on' in ovsrobot ? >> For example, patchew in QEMU parses 'Based-on: ' tags. >> Maybe we can use patchwork ids or something similar. > > I think there's a way to do it without a tag in the commit message. I > don't like having a tag for this sort of information in the commit > message itself since it isn't useful to preserve in the commit history > (and can serve to clutter things up). I don't like the idea having such tags in git log too. But we could place them under the cut line like in this patch. But, yes, developers will frequently misplace them in the main part of commit-message. OTOH, we could add a quick checkpatch rule for that. > > Currently, we use [PATCH branch-XXX] to imply that the series needs to > be based on a specific branch. The ovsrobot automatically creates > branches based on patch series. Maybe it makes sense to enhance that so > that some subject metadata marker (series-[0-9]+) would automatically > check out the series and then apply the patches. This also lets a > reviewer know at a glance that the patches are destined to be applied > after a specific series which is already posted. One downside is that > it's more subject line data. I can't think of others at the moment, but > I'm sure there are some. Since the robot doesn't currently clean up > branches, it's entirely possible to even base a series on a severely old > branch (so that should get fixed at some point). > > WDYT? Long subject lines is not a very good thing too. They hiding the patch subject in the mess of tags. Not sure what is better. Ben, do you have any thoughts about this? ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] hash: Implement hash for aarch64 using CRC32c intrinsics.
Bleep bloop. Greetings Yanqin Wei (Arm Technology China), I am a robot and I have tried out your patch. Thanks for your contribution. I encountered some error that I wasn't expecting. See the details below. git-am: fatal: corrupt patch at line 186 Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. Patch failed at 0001 hash: Implement hash for aarch64 using CRC32c intrinsics. The copy of the patch that failed is found in: /var/lib/jenkins/jobs/upstream_build_from_pw/workspace/.git/rebase-apply/patch When you have resolved this problem, run "git am --resolved". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". Please check this out. If you feel there has been an error, please email acon...@bytheb.org Thanks, 0-day Robot ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH v1 1/1] hash: Implement hash for aarch64 using CRC32c intrinsics.
This commit adds lib/hash-aarch64.h to implement hash for aarch64.
It is based on aarch64 built-in CRC32c intrinsics, which accelerates
hash function for datapath performance.
test:
1. "test-hash" case passed in aarch64 platform.
2. OVS-DPDK datapth performance test was run(NIC to NIC).
Test bed: aarch64(Centriq 2400) platform.
Test case: DPCLS forwarding(disable EMC + avg 10 subtable lookups)
Test result: improve around 10%.
Signed-off-by: Yanqin Wei
---
lib/automake.mk| 1 +
lib/hash-aarch64.h | 151 +
lib/hash.h | 5 +-
3 files changed, 156 insertions(+), 1 deletion(-)
create mode 100644 lib/hash-aarch64.h
diff --git a/lib/automake.mk b/lib/automake.mk
index b1ff495ff..ba1041095 100644
--- a/lib/automake.mk
+++ b/lib/automake.mk
@@ -100,6 +100,7 @@ lib_libopenvswitch_la_SOURCES = \
lib/guarded-list.h \
lib/hash.c \
lib/hash.h \
+ lib/hash-aarch64.h \
lib/hindex.c \
lib/hindex.h \
lib/hmap.c \
diff --git a/lib/hash-aarch64.h b/lib/hash-aarch64.h
new file mode 100644
index 0..6993e2a66
--- /dev/null
+++ b/lib/hash-aarch64.h
@@ -0,0 +1,151 @@
+/*
+ * Copyright (c) 2019 Arm Limited
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at:
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+/* This header implements HASH operation primitives on aarch64. */
+#ifndef HASH_AARCH64_H
+#define HASH_AARCH64_H 1
+
+#ifndef HASH_H
+#error "This header should only be included indirectly via hash.h."
+#endif
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+#include
+
+static inline uint32_t hash_add(uint32_t hash, uint32_t data)
+{
+return __crc32cw(hash, data);
+}
+
+/* Add the halves of 'data' in the memory order. */
+static inline uint32_t hash_add64(uint32_t hash, uint64_t data)
+{
+return __crc32cd(hash, data);
+}
+
+static inline uint32_t hash_finish(uint32_t hash, uint64_t final)
+{
+/* The finishing multiplier 0x805204f3 has been experimentally
+ * derived to pass the testsuite hash tests. */
+hash = __crc32cd(hash, final) * 0x805204f3;
+return hash ^ hash >> 16; /* Increase entropy in LSBs. */
+}
+
+/* Returns the hash of the 'n' 32-bit words at 'p_', starting from 'basis'.
+ * We access 'p_' as a uint64_t pointer.
+ *
+ * This is inlined for the compiler to have access to the 'n_words', which
+ * in many cases is a constant. */
+static inline uint32_t
+hash_words_inline(const uint32_t p_[], size_t n_words, uint32_t basis)
+{
+const uint64_t *p = (const void *)p_;
+uint32_t hash1 = basis;
+uint32_t hash2 = 0;
+uint32_t hash3 = n_words;
+const uint32_t *endp = (const uint32_t *)p + n_words;
+const uint64_t *limit = p + n_words / 2 - 3;
+
+while (p <= limit) {
+hash1 = __crc32cd(hash1, p[0]);
+hash2 = __crc32cd(hash2, p[1]);
+hash3 = __crc32cd(hash3, p[2]);
+p += 3;
+}
+switch (endp - (const uint32_t *)p) {
+case 1:
+hash1 = __crc32cw(hash1, *(const uint32_t *)&p[0]);
+break;
+case 2:
+hash1 = __crc32cd(hash1, p[0]);
+break;
+case 3:
+hash1 = __crc32cd(hash1, p[0]);
+hash2 = __crc32cw(hash2, *(const uint32_t *)&p[1]);
+break;
+case 4:
+hash1 = __crc32cd(hash1, p[0]);
+hash2 = __crc32cd(hash2, p[1]);
+break;
+case 5:
+hash1 = __crc32cd(hash1, p[0]);
+hash2 = __crc32cd(hash2, p[1]);
+hash3 = __crc32cw(hash3, *(const uint32_t *)&p[2]);
+break;
+}
+return hash_finish(hash1, (uint64_t)hash2 << 32 | hash3);
+}
+
+/* A simpler version for 64-bit data.
+ * 'n_words' is the count of 64-bit words, basis is 64 bits. */
+static inline uint32_t
+hash_words64_inline(const uint64_t p[], size_t n_words, uint32_t basis)
+{
+uint32_t hash1 = basis;
+uint32_t hash2 = 0;
+uint32_t hash3 = n_words;
+const uint64_t *endp = p + n_words;
+const uint64_t *limit = endp - 3;
+
+while (p <= limit) {
+hash1 = __crc32cd(hash1, p[0]);
+hash2 = __crc32cd(hash2, p[1]);
+hash3 = __crc32cd(hash3, p[2]);
+p += 3;
+}
+switch (endp - p) {
+case 1:
+hash1 = __crc32cd(hash1, p[0]);
+break;
+case 2:
+hash1 = __crc32cd(hash1, p[0]);
+hash2 = __crc32cd(hash2, p[1]);
+break;
+}
+return hash_finish(hash1, (uint64_t)hash2 << 32 | hash3);
+}
+
+static inline uint32_t hash_uint64_basis(const uint64_t x,
+
[ovs-dev] [PATCH] flow: fix udp checksum
As per RFC 768, if the calculated UDP checksum is 0, it should be
instead set as 0x in the frame. A value of 0 in the checksum
field indicates to the receiver that no checksum was calculated
and hence it should not verify the checksum.
Signed-off-by: Li RongQing
---
lib/flow.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/lib/flow.c b/lib/flow.c
index c60446ff4..c6e47781b 100644
--- a/lib/flow.c
+++ b/lib/flow.c
@@ -3023,6 +3023,9 @@ flow_compose_l4_csum(struct dp_packet *p, const struct
flow *flow,
udp->udp_csum = 0;
udp->udp_csum = csum_finish(csum_continue(pseudo_hdr_csum,
udp, l4_len));
+if (!udp->udp_csum) {
+udp->udp_csum = htons(0x);
+}
} else if (flow->nw_proto == IPPROTO_ICMP) {
struct icmp_header *icmp = dp_packet_l4(p);
--
2.16.2
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] MES SALUTATIONS
Bonjour Excusez moi de cette manière de vous contacter, je viens d'apercevoir votre profil et je me suis dis que vous êtes la personne qu'il me faut. Je suis Madame Aline BELLAT de nationalité française, hospitalisé en Europe pour raison de santé. Je souffre d'une tumeur au cerveau et le résultat de certaines de mes analyses médicales faisait état de ce que mes jours sur terre sont comptés. Malheureusement je n'ai ni famille ni enfant qui pourra bénéficier de cet argent. Il m'a été conseillé par le Père de mon église et guide spirituel d'en faire une donation afin que le SEIGNEUR me pardonne mes péchés car j'ai eu à effectuer des trafics illégaux dans divers domaines durant mon parcourt. Vous êtes donc bénéficiaire de 17.500.000 Euros. Je vous l'offre du fond du cœur. Veuillez l'accepter et faîtes-en bon usage. Je réclame juste des prières afin que mon opération se passe très bien. Veuillez donc écrire à mon mail personnel alinebel...@yahoo.com.ph pour rentrer en possession de votre donation car il vous appartient déjà dès à présent. QUE LES BÉNÉDICTION SOIENT AVEC VOUS Cordialement, ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [ovs-dev, v4] Monitor Database table to manage lifecycle of IDL client.
Still some failures. See inline. Best regards, Ilya Maximets. On 25.01.2019 4:51, Ted Elhourani wrote: > The Python IDL implementation supports ovsdb cluster connections. > This patch is a follow up to commit 31e434fc98, it adds the option of > connecting to the leader (the default) in the Raft-based cluster. It mimics > the exisiting C IDL support for clusters introduced in commit 1b1d2e6daa. > > The _Server database schema is first requested, then a monitor of the > Database table in the _Server Database. Method __check_server_db verifies > the eligibility of the server. If the attempt to obtain a monitor of the > _Server database fails and a cluster id was not provided this implementation > proceeds to request the data monitor. If a cluster id was provided via the > set_cluster_id method then the connection is aborted and a connection to a > different node is instead attempted, until a valid cluster node is found. > Thus, when supplied, cluster id is interpreted as the intention to only > allow connections to a clustered database. If not supplied, connections to > standalone nodes, or nodes that do not have the _Server database are > allowed. change_seqno is not incremented in the case of Database table > updates. > > Signed-off-by: Ted Elhourani > --- > > v3 -> v4 > > * export -f is not compatible with FreeBSD, modify tests to avoid shell > function export. > * Re-add a line that was removed by mistake. > > v2 -> v3 > > * Add 2 tests, treat cluster_id as a string, mv arg till end, pep8 fixes. > > v1 -> v2 > > * Modify for backward compatibility with _Server-less ovsdb servers. > > python/ovs/db/idl.py| 219 > > python/ovs/reconnect.py | 3 + > tests/ovsdb-idl.at | 128 +--- > tests/test-ovsdb.py | 67 ++- > 4 files changed, 371 insertions(+), 46 deletions(-) > > diff --git a/python/ovs/db/idl.py b/python/ovs/db/idl.py > index 250e897..84af978 100644 > --- a/python/ovs/db/idl.py > +++ b/python/ovs/db/idl.py > @@ -38,6 +38,8 @@ ROW_DELETE = "delete" > OVSDB_UPDATE = 0 > OVSDB_UPDATE2 = 1 > > +CLUSTERED = "clustered" > + > > class Idl(object): > """Open vSwitch Database Interface Definition Language (OVSDB IDL). > @@ -92,10 +94,13 @@ class Idl(object): > """ > > IDL_S_INITIAL = 0 > -IDL_S_MONITOR_REQUESTED = 1 > -IDL_S_MONITOR_COND_REQUESTED = 2 > +IDL_S_SERVER_SCHEMA_REQUESTED = 1 > +IDL_S_SERVER_MONITOR_REQUESTED = 2 > +IDL_S_DATA_MONITOR_REQUESTED = 3 > +IDL_S_DATA_MONITOR_COND_REQUESTED = 4 > > -def __init__(self, remote, schema_helper, probe_interval=None): > +def __init__(self, remote, schema_helper, probe_interval=None, > + leader_only=True): > """Creates and returns a connection to the database named 'db_name' > on > 'remote', which should be in a form acceptable to > ovs.jsonrpc.session.open(). The connection will maintain an > in-memory > @@ -119,6 +124,9 @@ class Idl(object): > > The IDL uses and modifies 'schema' directly. > > +If 'leader_only' is set to True (default value) the IDL will only > +monitor and transact with the leader of the cluster. > + > If "probe_interval" is zero it disables the connection keepalive > feature. If non-zero the value will be forced to at least 1000 > milliseconds. If None it will just use the default value in OVS. > @@ -137,6 +145,20 @@ class Idl(object): > self._last_seqno = None > self.change_seqno = 0 > self.uuid = uuid.uuid1() > + > +# Server monitor. > +self._server_schema_request_id = None > +self._server_monitor_request_id = None > +self._db_change_aware_request_id = None > +self._server_db_name = '_Server' > +self._server_db_table = 'Database' > +self.server_tables = None > +self._server_db = None > +self.server_monitor_uuid = uuid.uuid1() > +self.leader_only = leader_only > +self.cluster_id = None > +self._min_index = 0 > + > self.state = self.IDL_S_INITIAL > > # Database locking. > @@ -172,6 +194,12 @@ class Idl(object): > remotes.append(r) > return remotes > > +def set_cluster_id(self, cluster_id): > +"""Set the id of the cluster that this idl must connect to.""" > +self.cluster_id = cluster_id > +if self.state != self.IDL_S_INITIAL: > +self.force_reconnect() > + > def index_create(self, table, name): > """Create a named multi-column index on a table""" > return self.tables[table].rows.index_create(name) > @@ -222,7 +250,7 @@ class Idl(object): > if seqno != self._last_seqno: > self._last_seqno = seqno > self.__txn_abort_all() > -self.__send_monitor_request() > +
