On 10/18/21 18:50, Timothy Redaelli wrote:
On Mon, 18 Oct 2021 18:18:07 +0200
Adrian Moreno wrote:
On 10/18/21 14:51, Dumitru Ceara wrote:
On 10/14/21 6:41 PM, Adrian Moreno wrote:
ovn-detrace is a very useful tool for debugging OVN issues.
It's core logic (mapping openflow cookies /
On 10/18/21 18:48, Timothy Redaelli wrote:
On Thu, 14 Oct 2021 18:41:28 +0200
Adrian Moreno wrote:
For external python programs to be able to load ovn-detrace as a python
module easily, it should end in .py and should have underscores.
Move ovn-detrace to ovn-detrac.py and create a symlink
On 10/18/2021 11:14 PM, Eelco Chaudron wrote:
On 18 Oct 2021, at 14:03, Chris Mi wrote:
Hi Eelco,
On 10/15/2021 9:42 PM, Eelco Chaudron wrote:
Small comments inline, and Ilya please take a look at the first comment/request.
//Eelco
On 12 Oct 2021, at 10:19, Chris Mi wrote:
Some offload
Currently ingress policing uses the basic classifier to apply traffic
control filters if hardware offload is not enabled, else it uses
matchall. This change enables fallback onto the matchall classifier for
cases when the kernel is not built with basic support and hardware
offload is not in use.
On Mon, 18 Oct 2021 18:18:07 +0200
Adrian Moreno wrote:
>
>
> On 10/18/21 14:51, Dumitru Ceara wrote:
> > On 10/14/21 6:41 PM, Adrian Moreno wrote:
> >> ovn-detrace is a very useful tool for debugging OVN issues.
> >>
> >> It's core logic (mapping openflow cookies / ports with OVN objects) can
On Thu, 14 Oct 2021 18:41:28 +0200
Adrian Moreno wrote:
> For external python programs to be able to load ovn-detrace as a python
> module easily, it should end in .py and should have underscores.
>
> Move ovn-detrace to ovn-detrac.py and create a symlink with the old name
> for backwards
On Thu, 14 Oct 2021 18:41:28 +0200
Adrian Moreno wrote:
> For external python programs to be able to load ovn-detrace as a python
> module easily, it should end in .py and should have underscores.
>
> Move ovn-detrace to ovn-detrac.py and create a symlink with the old name
Nit: multiple typo
Hi Kevin,
> >
> > I wonder if the logs in the above function be INFO instead of DBG ?
> > Don't have a strong preference TBH. But if they were info, we need not
> remove any test cases no ?
> >
>
> The reason they are debug is so they won't pollute the logs when a rebalance
> cannot occur
Yup,
On 10/18/21 14:51, Dumitru Ceara wrote:
On 10/14/21 6:41 PM, Adrian Moreno wrote:
ovn-detrace is a very useful tool for debugging OVN issues.
It's core logic (mapping openflow cookies / ports with OVN objects) can
be used for a variety of troubleshooting tools. Therefore, it would be
Hi Aaron
We might for instance want to have some counters giving statistical data on
flow_mods added per ovn iteration.
So, for instance, we would be able to compare those statistics with
existing stopwatches indicating the time spent for those iterations, and
see whether a high time stopwatch is
On 18 Oct 2021, at 14:03, Chris Mi wrote:
> Hi Eelco,
>
> On 10/15/2021 9:42 PM, Eelco Chaudron wrote:
>> Small comments inline, and Ilya please take a look at the first
>> comment/request.
>>
>> //Eelco
>>
>>
>> On 12 Oct 2021, at 10:19, Chris Mi wrote:
>>
>>> Some offload actions require
On 18/10/2021 13:03, Pai G, Sunil wrote:
Hi Kevin,
Hi Sunil,
Thanks for reviewing.
Patch LGTM in general, just a query below.
+ * This function checks that some basic conditions needed for a
+rebalance to be
+ * effective are met. Such as Rxq scheduling assignment type, more than
+one
On 10/14/21 6:41 PM, Adrian Moreno wrote:
> ovn-detrace is a very useful tool for debugging OVN issues.
>
> It's core logic (mapping openflow cookies / ports with OVN objects) can
> be used for a variety of troubleshooting tools. Therefore, it would be
> desirable to make use of such logic from
Bleep bloop. Greetings Mark Gray, 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.
checkpatch:
WARNING: Comment with 'xxx' marker
#436 FILE: northd/northd.c:14423:
/* XXX Having to
On 18/10/2021 11:03, Mark Gray wrote:
> On 16/10/2021 02:21, Han Zhou wrote:
>> On Wed, Sep 29, 2021 at 10:23 AM Mark Gray wrote:
>>>
>>> Add the 'inc-proc-eng' framework to northd. This does *not*
>>> add any incremental processing at this stage but provides the
>>> framework to do so. Even in
Add an additional node that initially does nothing. This serves as a
template for how to add a new node. This node is inserted after
the northd_node.
This node will be updated in a later commit to generate logical
flows for the SBDB.
Signed-off-by: Mark Gray
---
northd/automake.mk | 2
'struct northd_data' is used to hold the output data from the
incremental processing node 'en_northd'. This will be used, in
a later commit, as the input data to 'en_lflow'. In order to achieve
this, we refactor in the following way:
* Introduce northd_init() which initializes this data.
*
Generate logical flows using 'en_flow' incremental processing node.
This node uses output data from 'en_northd' in order to generate
logical flows.
Signed-off-by: Mark Gray
---
northd/en-lflow.c | 12
northd/northd.c | 6 +-
northd/northd.h | 1 +
3 files changed, 14
In order to prepare for a subsequent commit, rename
'struct northd_context' to 'struct northd_idl_context'. In
subsequent commits, 'struct northd_idl_context' will then be
used, only, to hold the IDL context required by northd.
Signed-off-by: Mark Gray
---
northd/en-northd.c | 2 +-
Initial implementation adds a single node (northd). This single
node executes the northd processing pipeline but does not do so
incrementally.
In order to develop incremental processing for northd, the code
will be organised with a .c/.h file for each I-P node following
the naming convention
destroy_nat_entries() iterates over nat_entries using 'n_nat'
as the number of NAT entries from the NB database. This behaviour can be
incorrect as it assumes that there are 'n_nat' 'nat_entries'. 'struct
ovn_datapath' should maintain a count of 'nat_entries' in 'struct
ovn_datapath' rather than
Refactor ENGINE_NODE() macro to not assign function pointers. This
allows ENGINE_NODE() to be used outside functions, creating an
engine_node with global scope (but can be statically defined within a file).
This allows more flexibility in how the I-P engine can be used as
engine nodes can be
Add the 'inc-proc-eng' framework to northd. This does *not*
add any incremental processing at this stage but provides the
framework to do so. Even in this base configuration, we see an
advantage as northd no longer processes the databases if it has
been woken only to handle, for example, a unixctl
Hi Kevin,
Patch LGTM in general, just a query below.
> + * This function checks that some basic conditions needed for a
> +rebalance to be
> + * effective are met. Such as Rxq scheduling assignment type, more than
> +one
> + * PMD, more than 2 Rxqs on a PMD. If there was no reconfiguration
>
Hi Eelco,
On 10/15/2021 9:42 PM, Eelco Chaudron wrote:
Small comments inline, and Ilya please take a look at the first comment/request.
//Eelco
On 12 Oct 2021, at 10:19, Chris Mi wrote:
Some offload actions require functionality that is not netdev
based, but dpif. For example, sFlow action
On 10/14/21 5:17 PM, Lorenzo Bianconi wrote:
[...]
> diff --git a/controller/local_data.h b/controller/local_data.h
> index f6317e9ca..3defa9925 100644
> --- a/controller/local_data.h
> +++ b/controller/local_data.h
> @@ -154,5 +154,12 @@ bool get_chassis_tunnel_ofport(const struct hmap
>
On 10/14/21 5:17 PM, Lorenzo Bianconi wrote:
> Similar to if-status-mgr, track memory allocated for local_datapath.
>
> Signed-off-by: Lorenzo Bianconi
> ---
> controller/binding.c| 6 ++--
> controller/local_data.c | 66 +
>
On 10/14/21 5:17 PM, Lorenzo Bianconi wrote:
> Introduce memory accounting for data structures in ovn-controller
> if_status_mgr module.
>
> Signed-off-by: Lorenzo Bianconi
> ---
Acked-by: Dumitru Ceara
Thanks!
___
dev mailing list
There was typo in function pointer check in
dpif_bond_add() before calling bond_add()
Fixes: 9df65060cf4c ("userspace: Avoid dp_hash recirculation for balance-tcp
bond mode.")
Signed-off-by: Somnath Chatterjee
---
lib/dpif.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Bleep bloop. Greetings Mark Gray, 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.
build:
libtool: link: gcc -std=gnu99 -Wstrict-prototypes -Wall -Wextra
-Wno-sign-compare -Wpointer-arith
On 16/10/2021 02:21, Han Zhou wrote:
> On Wed, Sep 29, 2021 at 10:23 AM Mark Gray wrote:
>>
>> Add the 'inc-proc-eng' framework to northd. This does *not*
>> add any incremental processing at this stage but provides the
>> framework to do so. Even in this base configuration, we see an
>>
'struct northd_data' is used to hold the output data from the
incremental processing node 'en_northd'. This will be used, in
a later commit, as the input data to 'en_lflow'. In order to achieve
this, we refactor in the following way:
* Introduce northd_init() which initializes this data.
*
Add an additional node that initially does nothing. This serves as a
template for how to add a new node. This node is inserted after
the northd_node.
This node will be updated in a later commit to generate logical
flows for the SBDB.
Signed-off-by: Mark Gray
---
northd/automake.mk | 2
Generate logical flows using 'en_flow' incremental processing node.
This node uses output data from 'en_northd' in order to generate
logical flows.
Signed-off-by: Mark Gray
---
northd/en-lflow.c | 12
northd/northd.c | 6 +-
northd/northd.h | 1 +
3 files changed, 14
Initial implementation adds a single node (northd). This single
node executes the northd processing pipeline but does not do so
incrementally.
In order to develop incremental processing for northd, the code
will be organised with a .c/.h file for each I-P node following
the naming convention
In order to prepare for a subsequent commit, rename
'struct northd_context' to 'struct northd_idl_context'. In
subsequent commits, 'struct northd_idl_context' will then be
used, only, to hold the IDL context required by northd.
Signed-off-by: Mark Gray
---
northd/en-northd.c | 2 +-
destroy_nat_entries() iterates over nat_entries using 'n_nat'
as the number of NAT entries from the NB database. This behaviour can be
incorrect as it assumes that there are 'n_nat' 'nat_entries'. 'struct
ovn_datapath' should maintain a count of 'nat_entries' in 'struct
ovn_datapath' rather than
Refactor ENGINE_NODE() macro to not assign function pointers. This
allows ENGINE_NODE() to be used outside functions, creating an
engine_node with global scope (but can be statically defined within a file).
This allows more flexibility in how the I-P engine can be used as
engine nodes can be
Add the 'inc-proc-eng' framework to northd. This does *not*
add any incremental processing at this stage but provides the
framework to do so. Even in this base configuration, we see an
advantage as northd no longer processes the databases if it has
been woken only to handle, for example, a unixctl
39 matches
Mail list logo
