!È£úýRÎÏGµ"èô8?yø9]0³T1më%$>óËNû¿ªÞL'j¾à¨6b¥
vp·&§¥â).B!v&EV½8Ól
Í®ft³$ÎÙÒ5«æ6H1Ö-¦vÖïÂJ8:ØÅÝûEóFØR¯ýk$.¡ò¨GW7z¹g3Q[¤N¬§þ0
m¾¨üg
ë£*å¼3ûâZ9zÍã©Ù¡u°4GNx©÷Î~îGË<í ¼<:Dèþðªa
]Z&å;âµUHPXëZìÚçêÛØÓëßó
æ1H§scà Êzüò¡´í¥ï6¾5Í¥ÆÜîÊ 6¾³gU
1QÒIUwôø*gyÅïwéû&.$]¿ôpº5B'SeO9
Modify patch port name separators to use "--" instead of "-" so that
ovs-vtep plays nice with external tools such as Mininet which uses
dashes in port names. Without this change, ovs-vtep will throw a
ValueError exception and die soon after one of the physical ports
created by Mininet is attached t
Was there a particular tool or config flag that you used to detect this
error / generate this output?
On 8 September 2014 14:01, Pravin B Shelar wrote:
> packet execute is setting egress_tun_info in skb->cb, rather
> than packet->cb. skb is netlink msg skb. This causes corruption
> in netlink sk
> > This function has become a bit too long now, can you please refactor it?
> > One obvious thing you could do is to extract the processing of an
> > single NB into a separate function and the parent function can take
> > care of splitting the NBL (if required) & creating the right forwarding ct
On Fri, Sep 05, 2014 at 04:05:13PM -0700, Jarno Rajahalme wrote:
> When a whole field of a key value is ignored, skip it when formatting
> the key, and allow it to be left out when parsing the key from a
> string. However, when the unmasked bits have non-zero values (as in
> keys received from a d
Forgot to update the description,
Jarno
> On Sep 8, 2014, at 3:37 PM, Jarno Rajahalme wrote:
>
> dpif_netdev_execute may be called while doing upcall processing.
> Since the context of the input port is not tracked upto this point, we
> used the chared dp->emc_cache for packet execution. Exe
dpif_netdev_execute may be called while doing upcall processing.
Since the context of the input port is not tracked upto this point, we
used the chared dp->emc_cache for packet execution. Execution needs
to be able to pass the cache to recirculation code.
Typically the pmd threads use their own e
On Sep 8, 2014, at 1:09 PM, Daniele Di Proietto wrote:
> Hi Jarno,
>
> Thanks for figuring out this bug.
> I erroneously thought that since commit 623540e4617e (dpif-netdev:
> Streamline miss handling.) dpif_netdev_execute() could not be called
> anymore inside a dp_netdev_input() frame.
>
>
On 8 September 2014 22:23, Joe Stringer wrote:
> With v4 I've had a fairly good go at testing this series, for performance
> comparison and also compatibility with mixed older/newer
> datapath/userspace.
> Master appears to be able to revalidate roughly 130-140K flows per second
> with
> a single
On Sep 8, 2014, at 2:38 PM, Ben Pfaff wrote:
> On Fri, Sep 05, 2014 at 04:05:12PM -0700, Jarno Rajahalme wrote:
>> tp_src and tp_dst fields were recently added to struct flow_tnl, but
>> parsing and printing was missing.
>>
>> Signed-off-by: Jarno Rajahalme
>
> Thanks for the fix.
>
> This p
Thanks for the review, pushed to master,
Jarno
On Sep 8, 2014, at 2:34 PM, Ben Pfaff wrote:
> On Fri, Sep 05, 2014 at 04:05:11PM -0700, Jarno Rajahalme wrote:
>> Use the "+-" syntax more uniformly when printing masked flags, and use
>> the syntax of delimited 1-flags also for formatting fully
Pushed,
Jarno
On Sep 8, 2014, at 2:08 PM, Ben Pfaff wrote:
> On Fri, Sep 05, 2014 at 04:05:10PM -0700, Jarno Rajahalme wrote:
>> Some attributes are exact matches even when all bits are not ones.
>> Make odp_mask_attr_is_exact() to return true if the mask is set for
>> all the bits we actuall
Pushed,
Jarno
On Sep 8, 2014, at 12:18 PM, Ben Pfaff wrote:
> On Fri, Sep 05, 2014 at 04:05:09PM -0700, Jarno Rajahalme wrote:
>> is_all_zeros() and is_all_ones() operate on bytes, but just like with
>> memset, it is easier to use if the first argument is a void *.
>>
>> Signed-off-by: Jarno
On Sep 8, 2014, at 11:31 AM, Ben Pfaff wrote:
> On Fri, Sep 05, 2014 at 04:05:08PM -0700, Jarno Rajahalme wrote:
>> Add a new action type OVS_ACTION_ATTR_SET_MASKED, and support for
>> parsing, printing, and committing them.
>>
>> Masked set actions add a mask, immediately following the netlink
Thanks for the review!
It would be nice to have an Acked-by from you to the series. However, I plan to
squash trivial CodingStyle fixes in before pushing the series to master. Also,
I’ll add a News item stating that experimental RSTP is added, and more
compliance and interoperability testing is
On Mon, Sep 08, 2014 at 12:51:11PM -0700, Ethan Jackson wrote:
> > Is there any point to testing OVS in a configuration that we won't
> > distribute?
>
> This is a subject in which there could legitimately be many points of
> view, but I'll take a stab at explaining how I think about it.
>
> To a
On Fri, Sep 05, 2014 at 04:05:12PM -0700, Jarno Rajahalme wrote:
> tp_src and tp_dst fields were recently added to struct flow_tnl, but
> parsing and printing was missing.
>
> Signed-off-by: Jarno Rajahalme
Thanks for the fix.
This parsing and formatting code is looking more and more disastrous
On Fri, Sep 05, 2014 at 04:05:11PM -0700, Jarno Rajahalme wrote:
> Use the "+-" syntax more uniformly when printing masked flags, and use
> the syntax of delimited 1-flags also for formatting fully masked TCP
> flags.
>
> The "+-" syntax only deals with masked flags, but if there are many of
> tho
On Mon, Sep 8, 2014 at 2:14 PM, Andy Zhou wrote:
> Looks good to me.
> Acked-by: Andy Zhou
>
I pushed patch to master.
> BTW, did you figure out why gcc did not warning about the unused variable?
>
I am not sure, I will try to find it.
Thanks,
Pravin.
___
On 9 September 2014 02:10, Jarno Rajahalme wrote:
>
> > On Sep 8, 2014, at 3:23 AM, Joe Stringer wrote:
> >
> > It's highly unlikely that two flows will hash to the same UID. However,
> > we could handle multiple upcalls from the same flow. If we hash the flow
> > with an additional hash functio
Looks good to me.
Acked-by: Andy Zhou
BTW, did you figure out why gcc did not warning about the unused variable?
On Mon, Sep 8, 2014 at 12:56 PM, Pravin B Shelar wrote:
> Signed-off-by: Pravin B Shelar
> ---
> datapath/datapath.c | 26 --
> datapath/flow_netlink.c
On Fri, Sep 05, 2014 at 04:05:10PM -0700, Jarno Rajahalme wrote:
> Some attributes are exact matches even when all bits are not ones.
> Make odp_mask_attr_is_exact() to return true if the mask is set for
> all the bits we actually care about.
>
> Signed-off-by: Jarno Rajahalme
Acked-by: Ben Pfaf
Hi Jarno,
Thanks for figuring out this bug.
I erroneously thought that since commit 623540e4617e (dpif-netdev:
Streamline miss handling.) dpif_netdev_execute() could not be called
anymore inside a dp_netdev_input() frame.
I added the exact match cache on the non pmd-thread path for two reasons:
Thx, applied to master,
On Mon, Sep 8, 2014 at 11:18 AM, Ben Pfaff wrote:
> On Mon, Sep 08, 2014 at 11:13:34AM -0700, Alex Wang wrote:
> > On current master, when 'upcall_receive()' returns error, the
> > ofpbuf 'upcall->put_actions' is uninitialized. In some usecase,
> > the failure of 'upcall
Thx, applied to master,
On Mon, Sep 8, 2014 at 10:52 AM, Ben Pfaff wrote:
> On Mon, Sep 08, 2014 at 08:29:22AM -0700, Alex Wang wrote:
> > This commit updates the pointer to 'struct numa_node'
> > when initializing the 'struct cpu_core'.
> >
> > Signed-off-by: Alex Wang
>
> Acked-by: Ben Pfaff
Signed-off-by: Pravin B Shelar
---
datapath/datapath.c | 26 --
datapath/flow_netlink.c | 2 +-
datapath/flow_netlink.h | 2 +-
3 files changed, 14 insertions(+), 16 deletions(-)
diff --git a/datapath/datapath.c b/datapath/datapath.c
index d851cab..59f73d7 100644
--
> Is there any point to testing OVS in a configuration that we won't
> distribute?
This is a subject in which there could legitimately be many points of
view, but I'll take a stab at explaining how I think about it.
To answer your question: In general no, but with DPDK yes.
If you look at how st
We keep an outstanding, out of band, I/O request in the driver at all time.
Once an event generated the driver queues the event message, completes the
pending I/O and unblocks the calling thread through setting the event in the
overlapped structure n the NL socket. The thread will read all all eve
On Fri, Sep 05, 2014 at 04:05:09PM -0700, Jarno Rajahalme wrote:
> is_all_zeros() and is_all_ones() operate on bytes, but just like with
> memset, it is easier to use if the first argument is a void *.
>
> Signed-off-by: Jarno Rajahalme
Acked-by: Ben Pfaff
__
Please add the testing information to the commit message.
Also the usual way that we indicate the bug that a commit fixes is
with the Reported-at: tag at the end of a message.
Thanks,
Ben.
On Mon, Sep 08, 2014 at 06:53:26PM +, Samuel Ghinet wrote:
> I have tested:
> - vxlan
> - vlan (using
I have tested:
- vxlan
- vlan (using patch ports, as specified in INSTALL.Windows)
using:
- ping
- tcp
- tcp LSO (tcp segmentation)
I have put both the "each NB -> NBL" and its refactor in the same patch.
Thanks,
Sam
From: Samuel Ghinet
Sent: Monday, Sept
Hello, according to ovs-vsctl, we can add queues per ethernet port.
It looked like that it uses mechanisms which TC uses.
Is it right?
Does ovs support qos(with queue) for tunnel ports like gre, vxlan, and list
and so on?
Thanks,
Junguk
___
dev mailing
ovs/ovs-issues#15
All NET_BUFFERs of a NET_BUFFER_LIST must go through
the pipeline: extract, find flow, execute. Previously,
only the first NET_BUFFER of a NET_BUFFER_LIST was going
through this pipeline, which was erroneous.
OvsPartialCopyToMultipleNBLs is used to make each NET_BUFFER
have its
On Fri, Sep 05, 2014 at 04:05:08PM -0700, Jarno Rajahalme wrote:
> Add a new action type OVS_ACTION_ATTR_SET_MASKED, and support for
> parsing, printing, and committing them.
>
> Masked set actions add a mask, immediately following the netlink
> attribute data, within the netlink attribute itself.
This commit adds a new API to the 'struct netdev_class' which
allows user to query the numa node id the 'netdev' is on.
Currently, only netdev-dpdk module implements this function.
Signed-off-by: Alex Wang
---
PATCH -> V2
- rebase and refactor the code.
---
lib/netdev-bsd.c |1 +
lib/
The previous commit makes OVS create one tx queue for each
cpu core, each pmd thread will use a separate tx queue.
Also, tx of non-pmd threads on dpdk interface is all through
'NON_PMD_THREAD_TX_QUEUE', protected by the 'nonpmd_mempool_mutex'.
Therefore, the spinlock is no longer needed. And this
This commit adds new variable n_txq to 'struct netdev' for recording
the number of tx queues. Correspondingly, the send_*() functions are
extended to accept queue id as input argument.
All 'netdev-*' implementation will ignore the queue id since having
multiple tx queues is not supported. Upcomp
Before this commit, ovs creates one tx and one rx queue for
each dpdk interface and uses only one poll thread for handling
I/O of all dpdk interfaces. An upcoming patch will allow multiple
poll threads be created. As a preparation, this commit changes
the default to create multiple tx and rx queu
Previous commit makes OVS create one tx queue for each cpu
core. An upcoming patch will allow multiple pmd threads be
created and pinned to cpu cores. So each pmd thread will use
the tx queue corresponding to its core id.
Moreover, the pmd threads running on different numa node than
the dpdk int
With this commit, ovs by default will try creating 'number of
dpdk interfaces on numa node' pmd threads for each numa node
and pin the pmd threads to available cpu cores on the numa node.
NON_PMD_CORE_ID (currently 0) is used to reserve a particular
cpu core for the I/O of all non-pmd threads. No
On Mon, Sep 08, 2014 at 11:13:34AM -0700, Alex Wang wrote:
> On current master, when 'upcall_receive()' returns error, the
> ofpbuf 'upcall->put_actions' is uninitialized. In some usecase,
> the failure of 'upcall_receive()' will cause uninitialize of
> 'upcall->put_actions' and free of uninitiali
On current master, when 'upcall_receive()' returns error, the
ofpbuf 'upcall->put_actions' is uninitialized. In some usecase,
the failure of 'upcall_receive()' will cause uninitialize of
'upcall->put_actions' and free of uninitialized pointer.
This commit fixes the issue by making the caller not
Thx Ben,
> It's a little unusual for an initialization function that fails to
> still leave the object that it initializes ready to be destroyed. If
> upcall_receive() fails, is there other data in 'upcall' that needs to
> be destroyed?
No, I don't think there is other data to be destroyed..
On Mon, Sep 08, 2014 at 10:53:14AM -0700, Alex Wang wrote:
> On current master, when 'upcall_receive()' returns error, the
> ofpbuf 'upcall->put_actions' is uninitialized. In most cases,
> the failure of 'upcall_receive()' will cause uninitialize of
> 'upcall->put_actions' and free of uninitialize
On Mon, Sep 08, 2014 at 08:29:22AM -0700, Alex Wang wrote:
> This commit updates the pointer to 'struct numa_node'
> when initializing the 'struct cpu_core'.
>
> Signed-off-by: Alex Wang
Acked-by: Ben Pfaff
___
dev mailing list
dev@openvswitch.org
htt
On current master, when 'upcall_receive()' returns error, the
ofpbuf 'upcall->put_actions' is uninitialized. In most cases,
the failure of 'upcall_receive()' will cause uninitialize of
'upcall->put_actions' and free of uninitialized pointer.
This commit fixes the issue by making 'upcall_receive()
On Fri, Sep 05, 2014 at 02:20:57PM -0700, Ethan Jackson wrote:
> These options don't make sense when building portable code, but when
> using the dev script, OVS is built on the same system it's run on.
> They make a small difference in the OVS DPDK testing, hence their
> addition.
Is there any po
On Sun, Sep 7, 2014 at 11:26 PM, Joe Stringer wrote:
>
>
> On 8 September 2014 14:01, Pravin B Shelar wrote:
>>
>> packet execute is setting egress_tun_info in skb->cb, rather
>> than packet->cb. skb is netlink msg skb. This causes corruption
>> in netlink skb state stored in skb->cb (NETLINK_CB)
What does this mean? If you've accumulated acks then you should add
them to the commit message, not follow up with them.
On Fri, Sep 05, 2014 at 07:01:39PM +, Eitan Eliahu wrote:
> Acked-by: Alin Gabriel Serdean
> Acked-by: Ankur Sharma
>
> -Original Message-
> From: Eitan Eliahu [
On Mon, Sep 08, 2014 at 04:53:57PM +0530, Saloni Jain wrote:
> 1. Setting eviction using table-mod messages should not disturb the
> current ovs eviction configuration mechanism(without implementation
> of openflow specification 1.4). That means, if eviction is to be
> performed on the basis of lif
The subject should begin with a general area followed by a colon,
e.g. perhaps "datapath-windows:".
On Mon, Sep 08, 2014 at 02:41:14PM -0700, Eitan Eliahu wrote:
> We keep an outstanding, out of band, I/O request in the driver at all time.
> Once an event generated the driver queues the event mess
dpif_netdev_execute may be called while doing upcall processing.
Since the context of the input port is not tracked upto this point, we
used the chared dp->emc_cache for packet execution. Execution needs
to be able to pass the cache to recirculation code.
Typically the pmd threads use their own e
This commit updates the pointer to 'struct numa_node'
when initializing the 'struct cpu_core'.
Signed-off-by: Alex Wang
---
lib/ovs-numa.c |1 +
1 file changed, 1 insertion(+)
diff --git a/lib/ovs-numa.c b/lib/ovs-numa.c
index 4f0ba0d..7da1407 100644
--- a/lib/ovs-numa.c
+++ b/lib/ovs-numa.
> On Sep 8, 2014, at 3:23 AM, Joe Stringer wrote:
>
> It's highly unlikely that two flows will hash to the same UID. However,
> we could handle multiple upcalls from the same flow. If we hash the flow
> with an additional hash function and the hashes are the same, then the
> upcalls are most lik
We keep an outstanding, out of band, I/O request in the driver at all time.
Once an event generated the driver queues the event message, completes the
pending I/O and unblocks the calling thread through setting the event in the
overlapped structure n the NL socket. The thread will read all all eve
Thanks Sam!
Eitan
-Original Message-
From: Samuel Ghinet [mailto:sghi...@cloudbasesolutions.com]
Sent: Saturday, September 06, 2014 6:03 PM
To: dev@openvswitch.org; Eitan Eliahu
Cc: Alin Serdean
Subject: [ovs-dev] [PATCH] Windows NetLink Socket - Support for asynchronous
event notificati
On 09/03/14 at 11:24am, Jiri Pirko wrote:
> This patchset can be divided into 3 main sections:
> - introduce switchdev api for implementing switch drivers
> - add hardware acceleration bits into openvswitch datapath, This uses
> previously mentioned switchdev api
> - introduce rocker switch drive
This code shares code with the datapath dump functions. After we progress more
with the netlink commands, we will need to refactor: some common code will need
to be split to functions.
Also, the same as the current datapath dump command, the vport dump command is
not 100% complete, because it depe
Thanks a lot Ankur,
Sam
From: Ankur Sharma [ankursha...@vmware.com]
Sent: Sunday, September 07, 2014 8:20 PM
To: Samuel Ghinet; dev@openvswitch.org
Cc: Alin Serdean; Eitan Eliahu; Nithin Raju; Saurabh Shah
Subject: RE: [ovs-dev] [PATCH v2 2/6] NetlinkBuf.c:
On 8/25/14 3:33 AM, Jesse Gross wrote:
On Thu, Aug 21, 2014 at 12:24 PM, Lori Jakab wrote:
On 8/6/14 4:37 AM, Jesse Gross wrote:
Besides the fact that it would be nice to unify things, I'm not sure
that it is actually correct to pull off VLAN, MPLS, etc. tags that we
don't understand. Presumab
Heсoмнeнно нeοбxοдимр
имeть упpaвленцy и на
фиpме.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
Hi Ben/Team,
I am working on implementation of eviction mechanism as per openflow
specification 1.4 and thinking to contribute the same to openvswitch.
As per your previous inputs, the understanding of the feature is as follows:
Eviction mechanism is already present in openvswitch on the basis
It's highly unlikely that two flows will hash to the same UID. However,
we could handle multiple upcalls from the same flow. If we hash the flow
with an additional hash function and the hashes are the same, then the
upcalls are most likely from the same flow (assuming that the hash
collisions are d
Add the 128-bit murmurhash by Austin Appleby, for 32-bit systems from:
http://code.google.com/p/smhasher/source/browse/trunk/MurmurHash3.cpp
Signed-off-by: Joe Stringer
---
v4: Minor comments and style fixes.
v3: Rebase.
---
include/openvswitch/types.h |5 ++
lib/hash.c | 1
One of the limiting factors on the number of flows that can be supported
in the datapath is the overhead of assembling flow dump messages in the
datapath. This patch adds a new alternative to dumping the key, mask and
actions from the datapath, which is a 128-bit unique identifier for the
flow. For
This allows us to ignore most fields of a flow_dump, requiring only the
flow key for looking up the ukey. Fetching flows can also be avoided in
the corner case where a flow is missed from a dump but revalidation is
required.
A future patch will modify the datapath interface to make these cached
fi
We previously counted flows that have been installed during the current
dump as duplicates, rather than recognising them as new flows. This
patch separates the counters out for these two cases.
Signed-off-by: Joe Stringer
---
v4: Initial post.
---
ofproto/ofproto-dpif-upcall.c | 13 +--
If a datapath is created with the flag OVS_DP_F_INDEX_BY_UID, then an
additional table_instance is added to the flow_table, which is indexed
by unique identifiers ("UID"). This can be manipulated using the flow
key as before, or by using the new UID field. If both are specified,
then UID takes prec
When handler threads are installing ukeys, they hold the ukey mutex for
the duration of flow setup. If a revalidator thread dumps this flow
while the handler holds the lock, it will attempt to lock it using
ovs_mutex_trylock(), then if it cannot grab the lock, skip the flow.
Attempting to lock on
Currently, when a revalidator thread first dumps a flow, it creates a
'udpif_key' object and caches a copy of a kernel flow key. This allows
us to perform lookups in the classifier to attribute stats and validate
the correctness of the datapath flow.
This patch sets up this cache from the handler
Currently, udpif_keys are protected during revalidator_sweep__() as only
one thread accesses the ukey at a time. This is ensured using barriers:
all revalidators will be in the GC phase, so they will only access their
own ukey collection.
A future patch will change the access patterns to allow the
Future patches will make use of the 'struct dump_op' in a broader sense,
so this patch renames it to make things a bit clearer.
Signed-off-by: Joe Stringer
Acked-by: Ben Pfaff
---
v4: No change.
v3: Rebase.
v2: No change.
RFC: First post.
---
ofproto/ofproto-dpif-upcall.c | 95 +++
An upcoming patch will change the access patterns for ukey maps to
increase the number of writers, and shift write-access from revalidator
threads to upcall handler threads. As such, it no longer makes sense to
tie these maps to revalidators in a 1:1 relationship.
This patch separates the ukey map
With v4 I've had a fairly good go at testing this series, for performance
comparison and also compatibility with mixed older/newer datapath/userspace.
Master appears to be able to revalidate roughly 130-140K flows per second with
a single revalidator and many handlers. This series pushes this numbe
Signed-off-by: Joe Stringer
Acked-by: Ben Pfaff
---
v4: No change.
v3: Rebase.
v2: Call ovsrcu_quiesce() unconditionally.
RFC: Initial Post.
---
ofproto/ofproto-dpif-upcall.c | 61 ++---
1 file changed, 33 insertions(+), 28 deletions(-)
diff --git a/ofproto
--
*I am Beatrice Mbeki daughter of Late Wilfred Mbeki the group Chairman of
Castle & Gold Pacific Group Ltd. I will like to invest in any lucrative
business in your country as I do not have fair opportunities here.*
*Would you be in position to guide me towards this noble project. I will
appr
Gentile utente
Un virus HTTP è stato trovato sul nostro utente server.Email È istituito
requestted a presentare le seguenti informazioni qui di seguito per la verifica
e maintainace:
(1) E-mail:
(2) Nome:
(3) Password:
(4) Conferma Password:
grazie
Web Team
___
77 matches
Mail list logo
