[ovs-dev] Mr.Samuel Durojaye
I Am Mr.Samuel Durojaye, Director, Foreign Remittance Department- Wema bank of
Nigeria. I am contacting based on a recent meeting held with the Office of the
Presidency, Federal Republic of Nigeria in conjunction with the Federal
Ministry of Finance and Senate committee on Budget and planning,National
Assembly.
After the meeting, it was agreed to pay James Lee for his overdue contract
payment of Five Million United States Dollars Only {US$5,000,000.00} out of his
long complicated outstanding payment. but this Mr Lee died in motor accident so
am fronting you as his next of kin.
Considering the circumstance that threw up this opportunity,I am willing and
prepared to use my good office and power to get it released to you either in
cash ,to be delivered to your door step at any address of your choice but on
the condition that it shall be shared 50/50% between us.
I have what it takes to deliver on this transaction in maximum of 7 banking
days devoid of any risk not hitch.All I need to initiate action in the matter
is your formal consent by way of reverting to me with below itemised
information should you settle for secured Cash Delivery to your address:-
Your full name:
Private telephone number:
Choice of address {where you wish the consignment delivered}:
God is with us as we wait for your reply.
Yours faithfully,
Mr.Samuel Durojaye
Direct tel.no:+234-7081540754
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] datapath: Add hash info to upcall.
On Thu, May 7, 2020 at 11:21 PM Tonghao Zhang
wrote:
>
> On Mon, May 4, 2020 at 9:02 AM Han Zhou wrote:
> >
> > This patch backports below upstream patches, and add __skb_set_hash
> > to compat for older kernels.
> >
> > commit b5ab1f1be6180a2e975eede18731804b5164a05d
> > Author: Jakub Kicinski
> > Date: Mon Mar 2 21:05:18 2020 -0800
> >
> > openvswitch: add missing attribute validation for hash
> >
> > Add missing attribute validation for OVS_PACKET_ATTR_HASH
> > to the netlink policy.
> >
> > Fixes: bd1903b7c459 ("net: openvswitch: add hash info to upcall")
> > Signed-off-by: Jakub Kicinski
> > Reviewed-by: Greg Rose
> > Signed-off-by: David S. Miller
> >
> > commit bd1903b7c4596ba6f7677d0dfefd05ba5876707d
> > Author: Tonghao Zhang
> > Date: Wed Nov 13 23:04:49 2019 +0800
> >
> > net: openvswitch: add hash info to upcall
> >
> > When using the kernel datapath, the upcall don't
> > include skb hash info relatived. That will introduce
> > some problem, because the hash of skb is important
> > in kernel stack. For example, VXLAN module uses
> > it to select UDP src port. The tx queue selection
> > may also use the hash in stack.
> >
> > Hash is computed in different ways. Hash is random
> > for a TCP socket, and hash may be computed in hardware,
> > or software stack. Recalculation hash is not easy.
> >
> > Hash of TCP socket is computed:
> > tcp_v4_connect
> > -> sk_set_txhash (is random)
> >
> > __tcp_transmit_skb
> > -> skb_set_hash_from_sk
> >
> > There will be one upcall, without information of skb
> > hash, to ovs-vswitchd, for the first packet of a TCP
> > session. The rest packets will be processed in Open vSwitch
> > modules, hash kept. If this tcp session is forward to
> > VXLAN module, then the UDP src port of first tcp packet
> > is different from rest packets.
> >
> > TCP packets may come from the host or dockers, to Open vSwitch.
> > To fix it, we store the hash info to upcall, and restore hash
> > when packets sent back.
> >
> > +---+ +-+
> > | Docker/VMs | | ovs-vswitchd|
> > ++--+ +-++--+
> > | ^|
> > | ||
> > | | upcallv restore packet
hash
> > (not recalculate)
> > | +-++--+
> > | tap netdev | | vxlan
module
> > +---> +--> Open vSwitch ko +-->
> >or internal type| |
> >+-+
> >
> > Reported-at:
https://mail.openvswitch.org/pipermail/ovs-dev/2019-October/364062.html
> > Signed-off-by: Tonghao Zhang
> > Acked-by: Pravin B Shelar
> > Signed-off-by: David S. Miller
> >
> > Cc: Tonghao Zhang
> > Signed-off-by: Han Zhou
> Reviewed-by: Tonghao Zhang
Thanks review from Tonghao and Greg.
It has been 3 weeks, so cc some maintainers and pop it up.
> > ---
> > acinclude.m4 | 2 ++
> > datapath/datapath.c | 27
++-
> > datapath/datapath.h | 12
> > datapath/linux/compat/include/linux/skbuff.h | 10 ++
> > 4 files changed, 50 insertions(+), 1 deletion(-)
> >
> > diff --git a/acinclude.m4 b/acinclude.m4
> > index dabbffd..5e5ca39 100644
> > --- a/acinclude.m4
> > +++ b/acinclude.m4
> > @@ -1101,6 +1101,8 @@ AC_DEFUN([OVS_CHECK_LINUX_COMPAT], [
> >OVS_FIND_OP_PARAM_IFELSE([$KSRC/include/net/rtnetlink.h],
> > [validate], [extack],
> >
[OVS_DEFINE([HAVE_RTNLOP_VALIDATE_WITH_EXTACK])])
> > + OVS_GREP_IFELSE([$KSRC/include/linux/skbuff.h],
> > + [__skb_set_hash])
> >
> >if cmp -s datapath/linux/kcompat.h.new \
> > datapath/linux/kcompat.h >/dev/null 2>&1; then
> > diff --git a/datapath/datapath.c b/datapath/datapath.c
> > index a7af784..82f5688 100644
> > --- a/datapath/datapath.c
> > +++ b/datapath/datapath.c
> > @@ -371,7 +371,8 @@ static size_t upcall_msg_size(const struct
dp_upcall_info *upcall_info,
> > size_t size = NLMSG_ALIGN(sizeof(struct ovs_header))
> > + nla_total_size(hdrlen) /* OVS_PACKET_ATTR_PACKET */
> > + nla_total_size(ovs_key_attr_size()) /*
OVS_PACKET_ATTR_KEY */
> > - + nla_total_size(sizeof(unsigned int)); /*
OVS_PACKET_ATTR_LEN */
> > + + nla_total_size(sizeof(unsigned int)) /*
OVS_PACKET_ATTR_LEN */
> > + + nla_total_size(sizeof(u64)); /* OVS_PACKET_ATTR_HASH
*/
> >
> > /* OVS_PACKET_ATTR_USERDATA */
> > if (upcall_info->userdata)
> > @@ -414,6 +415,7 @@
Re: [ovs-dev] [PATCH] compat: Backport ipv6_stub change
On Thu, May 21, 2020 at 02:54:03PM -0700, Greg Rose wrote:
> A patch backported to the Linux stable 4.14 tree and present in the
> latest stable 4.14.181 kernel breaks ipv6_stub usage.
>
> The commit is
> 8ab8786f78c3 ("net ipv6_stub: use ip6_dst_lookup_flow instead of
> ip6_dst_lookup").
>
> Create the compat layer define to check for it and fixup usage in vxlan
> and geneve modules.
>
> Passes Travis here:
> https://travis-ci.org/github/gvrose8192/ovs-experimental/builds/689798733
>
> Signed-off-by: Greg Rose
Thanks for fixing the travis failure.
Applied to master.
William
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] netdev-offload-dpdk: Support offload of VLAN PUSH/POP actions
On Sun, May 24, 2020 at 2:52 PM Tonghao Zhang wrote:
>
> On Sun, May 24, 2020 at 3:38 PM Sriharsha Basavapatna via dev
> wrote:
> >
> > Parse VLAN PUSH/POP OVS datapath actions and add respective RTE actions.
> One question, if pop vlan in the hw, then process it in userspace
> datapath, the metadata of vlan should restore it.
It is not processed in userspace datapath. The packet is processed and
forwarded entirely in HW (full-offload/SR-IOV VF use case).
> I guess pop_vlan/pop_vxlan are same case. right ?
No, they are not. pop_vlan pops the vlan tag in the packet.
vxlan_decap pops the vxlan tunnel header.
Thanks,
-Harsha
> > Signed-off-by: Sriharsha Basavapatna
> > ---
> > lib/netdev-offload-dpdk.c | 34 ++
> > 1 file changed, 34 insertions(+)
> >
> > diff --git a/lib/netdev-offload-dpdk.c b/lib/netdev-offload-dpdk.c
> > index f8c46bbaa..9d7c0d4ce 100644
> > --- a/lib/netdev-offload-dpdk.c
> > +++ b/lib/netdev-offload-dpdk.c
> > @@ -970,6 +970,33 @@ parse_set_actions(struct flow_actions *actions,
> > return 0;
> > }
> >
> > +static int
> > +parse_vlan_push_action(struct flow_actions *actions,
> > + const struct ovs_action_push_vlan *vlan_push)
> > +{
> > +struct rte_flow_action_of_push_vlan *rte_push_vlan;
> > +struct rte_flow_action_of_set_vlan_pcp *rte_vlan_pcp;
> > +struct rte_flow_action_of_set_vlan_vid *rte_vlan_vid;
> > +
> > +rte_push_vlan = xzalloc(sizeof *rte_push_vlan);
> > +rte_push_vlan->ethertype = vlan_push->vlan_tpid;
> > +add_flow_action(actions, RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN,
> > +rte_push_vlan);
> > +
> > +rte_vlan_pcp = xzalloc(sizeof *rte_vlan_pcp);
> > +rte_vlan_pcp->vlan_pcp = vlan_tci_to_pcp(vlan_push->vlan_tci);
> > +add_flow_action(actions, RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_PCP,
> > +rte_vlan_pcp);
> > +
> > +rte_vlan_vid = xzalloc(sizeof *rte_vlan_vid);
> > +rte_vlan_vid->vlan_vid =
> > +rte_cpu_to_be_16(vlan_tci_to_vid(vlan_push->vlan_tci));
> > +add_flow_action(actions, RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID,
> > +rte_vlan_vid);
> > +
> > +return 0;
> > +}
> > +
> > static int
> > parse_flow_actions(struct netdev *netdev,
> > struct flow_actions *actions,
> > @@ -998,6 +1025,13 @@ parse_flow_actions(struct netdev *netdev,
> >masked)) {
> > return -1;
> > }
> > +} else if (nl_attr_type(nla) == OVS_ACTION_ATTR_PUSH_VLAN) {
> > +const struct ovs_action_push_vlan *vlan = nl_attr_get(nla);
> > +if (parse_vlan_push_action(actions, vlan)) {
> > +return -1;
> > +}
> > +} else if (nl_attr_type(nla) == OVS_ACTION_ATTR_POP_VLAN) {
> > +add_flow_action(actions, RTE_FLOW_ACTION_TYPE_OF_POP_VLAN,
> > NULL);
> > } else {
> > VLOG_DBG_RL(, "Unsupported action type %d",
> > nl_attr_type(nla));
> > return -1;
> > --
> > 2.25.0.rc2
> >
> > ___
> > dev mailing list
> > d...@openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
>
>
> --
> Best regards, Tonghao
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] MY HUMBLE REQUEST
My Dear I am Mrs. Anna Cooper, from Australia, lived in South Africa for 20 years and currently residing in London United Kingdom, a widow to late Dr. Andrew Cooper. I am 75 years old, and presently suffering from Leukemia. My health condition has gotten worse and just two weeks ago my doctor informed me that my condition has reach a critical stage, and that I have just 3 months left. This confirmation from my doctor was and still is a devastating news, it is hard to know that you have just a little time left to live here. My late husband was a contractor in both South Africa and London, he died in a plane crash and during the period of our marriage we could not bear any child. My late husband was very wealthy and after his death, I inherited all his businesses and wealth both in South Africa and London-United Kingdom. After the doctor’s medical pronunciation that I have just few months to live, I decided to divide my wealth to contribute to your country and Africa where my late husband as a contractor made lots of money. I want to assist you with the funds to do great charity works in your country, this is my last wish. I selected you after searching few websites; I prayed and was led to you. I am willing to donate the sum of Four Million, Six Hundred thousand United States Dollars (USD$4,600,000.00) to the less privileged through you. Please I want to transfer this money to you as I am travelling to South Africa soonest to have my lawyer amend my WILL. If you can handle this fund and very sure to do charity works on my behalf then I will include your name in my WILL when in South Africa, and from there I will travel to Australia to meet a specialist as I want to be buried alongside my late husband when I passed on. Note that this fund is in the financial institution and upon my instruction; I will file in an application through my family attorney for the transfer of the money into your account for the said purpose. Lastly, I honestly pray that this money when transferred will be used for the said purpose even though I might be late then. I have come to find out that wealth is vanity and I made a promise to God that my wealth will be used to support the poor and the assist the sick. Do let me know if you will be able to handle this fund and use it for the said purpose so that I will inform my attorney and my bank on my decision. Reply to me using: annacooper02...@gmail.com God bless you. Mrs. Anna Cooper. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH] netdev-offload-dpdk: Support offload of VLAN PUSH/POP actions
On Sun, May 24, 2020 at 3:38 PM Sriharsha Basavapatna via dev
wrote:
>
> Parse VLAN PUSH/POP OVS datapath actions and add respective RTE actions.
One question, if pop vlan in the hw, then process it in userspace
datapath, the metadata of vlan should restore it.
I guess pop_vlan/pop_vxlan are same case. right ?
> Signed-off-by: Sriharsha Basavapatna
> ---
> lib/netdev-offload-dpdk.c | 34 ++
> 1 file changed, 34 insertions(+)
>
> diff --git a/lib/netdev-offload-dpdk.c b/lib/netdev-offload-dpdk.c
> index f8c46bbaa..9d7c0d4ce 100644
> --- a/lib/netdev-offload-dpdk.c
> +++ b/lib/netdev-offload-dpdk.c
> @@ -970,6 +970,33 @@ parse_set_actions(struct flow_actions *actions,
> return 0;
> }
>
> +static int
> +parse_vlan_push_action(struct flow_actions *actions,
> + const struct ovs_action_push_vlan *vlan_push)
> +{
> +struct rte_flow_action_of_push_vlan *rte_push_vlan;
> +struct rte_flow_action_of_set_vlan_pcp *rte_vlan_pcp;
> +struct rte_flow_action_of_set_vlan_vid *rte_vlan_vid;
> +
> +rte_push_vlan = xzalloc(sizeof *rte_push_vlan);
> +rte_push_vlan->ethertype = vlan_push->vlan_tpid;
> +add_flow_action(actions, RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN,
> +rte_push_vlan);
> +
> +rte_vlan_pcp = xzalloc(sizeof *rte_vlan_pcp);
> +rte_vlan_pcp->vlan_pcp = vlan_tci_to_pcp(vlan_push->vlan_tci);
> +add_flow_action(actions, RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_PCP,
> +rte_vlan_pcp);
> +
> +rte_vlan_vid = xzalloc(sizeof *rte_vlan_vid);
> +rte_vlan_vid->vlan_vid =
> +rte_cpu_to_be_16(vlan_tci_to_vid(vlan_push->vlan_tci));
> +add_flow_action(actions, RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID,
> +rte_vlan_vid);
> +
> +return 0;
> +}
> +
> static int
> parse_flow_actions(struct netdev *netdev,
> struct flow_actions *actions,
> @@ -998,6 +1025,13 @@ parse_flow_actions(struct netdev *netdev,
>masked)) {
> return -1;
> }
> +} else if (nl_attr_type(nla) == OVS_ACTION_ATTR_PUSH_VLAN) {
> +const struct ovs_action_push_vlan *vlan = nl_attr_get(nla);
> +if (parse_vlan_push_action(actions, vlan)) {
> +return -1;
> +}
> +} else if (nl_attr_type(nla) == OVS_ACTION_ATTR_POP_VLAN) {
> +add_flow_action(actions, RTE_FLOW_ACTION_TYPE_OF_POP_VLAN, NULL);
> } else {
> VLOG_DBG_RL(, "Unsupported action type %d",
> nl_attr_type(nla));
> return -1;
> --
> 2.25.0.rc2
>
> ___
> dev mailing list
> d...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
--
Best regards, Tonghao
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] More Details.
Calvary Greetings Beloved , How are you today , It’s my pleasure to finally getting a chance to write you. I would like to be sure that your email is active please respond to me as soon as possible I will like to donate for Charity please hear me out. I’m not sure what the time is now in your location but do have a great day and stay safe. Regards Jane Norah. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
[ovs-dev] [PATCH] netdev-offload-dpdk: Support offload of VLAN PUSH/POP actions
Parse VLAN PUSH/POP OVS datapath actions and add respective RTE actions.
Signed-off-by: Sriharsha Basavapatna
---
lib/netdev-offload-dpdk.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/lib/netdev-offload-dpdk.c b/lib/netdev-offload-dpdk.c
index f8c46bbaa..9d7c0d4ce 100644
--- a/lib/netdev-offload-dpdk.c
+++ b/lib/netdev-offload-dpdk.c
@@ -970,6 +970,33 @@ parse_set_actions(struct flow_actions *actions,
return 0;
}
+static int
+parse_vlan_push_action(struct flow_actions *actions,
+ const struct ovs_action_push_vlan *vlan_push)
+{
+struct rte_flow_action_of_push_vlan *rte_push_vlan;
+struct rte_flow_action_of_set_vlan_pcp *rte_vlan_pcp;
+struct rte_flow_action_of_set_vlan_vid *rte_vlan_vid;
+
+rte_push_vlan = xzalloc(sizeof *rte_push_vlan);
+rte_push_vlan->ethertype = vlan_push->vlan_tpid;
+add_flow_action(actions, RTE_FLOW_ACTION_TYPE_OF_PUSH_VLAN,
+rte_push_vlan);
+
+rte_vlan_pcp = xzalloc(sizeof *rte_vlan_pcp);
+rte_vlan_pcp->vlan_pcp = vlan_tci_to_pcp(vlan_push->vlan_tci);
+add_flow_action(actions, RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_PCP,
+rte_vlan_pcp);
+
+rte_vlan_vid = xzalloc(sizeof *rte_vlan_vid);
+rte_vlan_vid->vlan_vid =
+rte_cpu_to_be_16(vlan_tci_to_vid(vlan_push->vlan_tci));
+add_flow_action(actions, RTE_FLOW_ACTION_TYPE_OF_SET_VLAN_VID,
+rte_vlan_vid);
+
+return 0;
+}
+
static int
parse_flow_actions(struct netdev *netdev,
struct flow_actions *actions,
@@ -998,6 +1025,13 @@ parse_flow_actions(struct netdev *netdev,
masked)) {
return -1;
}
+} else if (nl_attr_type(nla) == OVS_ACTION_ATTR_PUSH_VLAN) {
+const struct ovs_action_push_vlan *vlan = nl_attr_get(nla);
+if (parse_vlan_push_action(actions, vlan)) {
+return -1;
+}
+} else if (nl_attr_type(nla) == OVS_ACTION_ATTR_POP_VLAN) {
+add_flow_action(actions, RTE_FLOW_ACTION_TYPE_OF_POP_VLAN, NULL);
} else {
VLOG_DBG_RL(, "Unsupported action type %d", nl_attr_type(nla));
return -1;
--
2.25.0.rc2
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH ovn v7 5/9] ovn-controller: I-P for ct zone and OVS interface changes in flow output stage.
On Sat, May 23, 2020 at 11:37 AM Numan Siddique wrote: > > > > On Sat, May 23, 2020 at 7:30 AM Han Zhou wrote: >> >> On Fri, May 22, 2020 at 10:29 AM Numan Siddique wrote: >> > >> > >> > >> > On Thu, May 21, 2020 at 12:02 PM Han Zhou wrote: >> >> >> >> On Wed, May 20, 2020 at 12:41 PM wrote: >> >> > >> >> > From: Numan Siddique >> >> > >> >> > This patch handles ct zone changes and OVS interface changes >> incrementally >> >> > in the flow output stage. >> >> > >> >> > Any changes to ct zone can be handled by running physical_run() instead >> >> of running >> >> > flow_output_run(). And any changes to OVS interfaces can be either >> handled >> >> > incrementally (for OVS interfaces representing VIFs) or just running >> >> > physical_run() (for tunnel and other types of interfaces). >> >> > >> >> > To better handle this, a new engine node 'physical_flow_changes' is >> added >> >> which >> >> > handles changes to ct zone and OVS interfaces. >> >> > >> >> Hi Numan, >> >> >> > Hi Han, >> > >> > Thanks for the review and comments. Please see below. >> > >> > >> >> >> >> The engine node physical_flow_changes looks weird because it doesn't >> really >> >> have any data but merely to trigger some compute when VIF changes. >> >> I think it can be handled in a more straightforward way. In fact there >> was >> >> a miss in my initial I-P patch that there are still global variables used >> >> in physical.c (my bad): >> >> - localvif_to_ofport >> >> - tunnels >> >> In the principle of I-P engine global variable shouldn't be used because >> >> otherwise there is no way to ensure the dependency graph is followed. The >> >> current I-P is sitll correct only because interface changes (which in >> turn >> >> causes the above global var changes) always triggers recompute. >> >> >> >> Now to handle interface changes incrementally, we should simply move >> these >> >> global vars to engine nodes, and add them as input for flow_output, and >> >> also their input will be OVS_Interface (and probably some other inputs). >> >> With this, the dependency graph would be clear and implementation of each >> >> input handler will be straightforward. Otherwise, it would be really hard >> >> to follow the logic and deduce the correctness for all corner cases, >> >> although it may be correct for normal scenarios that I believe you have >> >> done thorough tests. Do you mind refactoring it? >> > >> > >> > Right now, the flow_output node has an "en_ct_zones" engine as input and >> it doesn't have >> > OVS_interface as input. But this is ok as any runtime data change will >> trigger recomputing. >> > >> Do you mean OVS_interface should actually be input of "en_ct_zones", but it >> is ok to not add it? But I don't understand why should it be input of >> en_ct_zones. Maybe I missed something? > > > I mean right now, OVS Interface is not an input to flow_output stage. > >> >> My point above is about the dependency between flow_output and >> OVS_interface. flow_output actually depends on OVS_interface. The two >> global variables allowed flow_output to use OVS_interface data without the >> dependancy in the graph. Now since we incrementally procssing OVS_interface >> changes, we'd better fix the dependency graph to ensure the correctness. > > > I agree. > > >> >> I >> had encounted very tricky bugs even when some very trivial part of the I-P >> engine rule was not followed, and finally found out defining the engine >> node properly was the easiest fix. >> >> > If en_ct_zones engine node changes, there is no need to trigger full >> recompute and we >> > call "physical_run()", it should be enough. Although we can definitely >> further improve it >> > and this can be tackled separately. >> > >> > In my understanding, I think we can also handle ovs interface changes >> incrementally and if we can't >> > we can just call "physical_run()" instead of full flow recompute. >> > >> > With this patch, it adds an engine node for physical flow changes and the >> input for that is en_ct_zone >> > and ovs interface. I understand and agree that it's a bit weird. >> > >> > How to handle it when both >> >- en_ct_zone changes >> >- some ovs interface changes. >> > >> > If both these inputs are direct inputs to the flow_output engine, then we >> may end up calling "physical_run()" >> > twice. And I wanted to avoid that and hence added a physical_flow_changes >> node as an intermediate. >> > How do you suggest we handle this if we directly handle the ovs interface >> changes in flow_output engine ? >> > >> >> Not sure if I understand completely, but it seems you are suggesting we can >> afford a recompute for physical flows, but not for logical flows, and in >> some cases this can happen. Hoewver, you are trying to make a full phyical >> computing appear as incremental processing, but you are not happy with this >> kind of I-P because the cost is high, so you want to avoid calling it >> multiple times, so a intermediate node is added for that purpose.
