Re: [ovs-discuss] [OVN]: IP address representing external destinations

[Han Zhou]

On Wed, Sep 16, 2020 at 10:07 AM Alexander Constantinescu <
acons...@redhat.com> wrote:

> In this example it is equivalent to just "ip4.src == 10.244.2.5/32"'.
>>
>
> Yes, I was just using it as an example (though, granted, noop example)
>
> Some background to help steer the discussion:
>
> Essentially the functionality here is to have south -> north traffic from
> certain logical switch ports exit the cluster through a dedicated node (an
> egress node if you will). To do this we currently have a set of default
> logical router policies, intended to leave east <-> west traffic untouched,
> and then logical router policies with a lower priority, which specify
> reroute actions for this functionality to happen. However, on large
> clusters, there's this concern that the default logical router policies
> will become too many. Hence why the idea here would be to drop them
> completely and have this "special IP" that we can use to filter on the
> destination, south -> north, traffic .
>
> If you have a default route, anything "unknown" would just hit the default
>> route, right? Why would you need another IP for this purpose?
>>
>
> As to remove the default logical router policies, which can become a
> lot, on big clusters - as described above. With only reroute policies of
> type: "ip4.src == 10.244.2.5/32 && ip4.dst == SOUTH_TO_NORTH_IP" things
> would become lighter.
>

Thanks for the background. So you have:


...
default route (lowest priority): ip4.src == ,
nexthop = 
default route (lowest priority): ip4.src == ,
nexthop = 

Is this the current situation?
When you say there are too many default routes, what do you mean in the
above example? How would the SOUTH_TO_NORTH_IP solve the problem?

In addition, if SOUTH_TO_NORTH_IP is a user defined IP, I am not sure how
would it work, because ip4.dst is the dst IP from packet header. Comparing
it with SOUTH_TO_NORTH_IP would just result in mismatch, unless all
south-to-north traffic really has this IP as destination (I guess that's
not the case).


>  In policies/ACL you will need to make sure the priorities are set
>> properly to achieve the default-route behavior.
>>
>
> Yes, so this is currently done, as described above.
>
> On Wed, Sep 16, 2020 at 6:35 PM Han Zhou  wrote:
>
>>
>>
>> On Wed, Sep 16, 2020 at 5:42 AM Alexander Constantinescu <
>> acons...@redhat.com> wrote:
>> >
>> > Hi
>> >
>> > I was wondering if anybody is aware of an IP address signifying
>> "external IP destinations"?
>> >
>> > Currently in OVN we can use the IP address 0.0.0.0/0 for match
>> expressions in logical routing policies / ACLs when we want to specify a
>> source or destination IP equating to the pseudo term: "all IP
>> addresses",ex: 'match="ip4.src == 10.244.2.5/32 && ip4.dst ==0.0.0.0/0"'
>> >
>> In this example it is equivalent to just "ip4.src == 10.244.2.5/32"'.
>>
>> > Essentially what I would need to do for an OVN-Kubernetes feature is
>> specify such a match condition for south -> north traffic, i.e when the
>> destination IP address is external to the cluster, and most likely
>> "unknown" to OVN. Thus, when OVN does not know how to route it within the
>> OVN network topology and has no choice except sending it out the default
>> route.
>> >
>> > Do we have such an IP address in OVN/OVS? Would it be feasible to
>> introduce, in case there is none?
>> >
>> We don't have such a special IP except 0.0.0.0/0. If you have a default
>> route, anything "unknown" would just hit the default route, right? Why
>> would you need another IP for this purpose? In logical_router_static_route
>> the priority is based on prefix length. In policies/ACL you will need to
>> make sure the priorities are set properly to achieve the default-route
>> behavior.
>>
>> Thanks,
>> Han
>>
>> > Thanks in advance!
>> >
>> > --
>> >
>> > Best regards,
>> >
>> >
>> > Alexander Constantinescu
>> >
>> > Software Engineer, Openshift SDN
>> >
>> > Red Hat
>> >
>> > acons...@redhat.com
>> >
>> > ___
>> > discuss mailing list
>> > disc...@openvswitch.org
>> > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>>
>
>
> --
>
> Best regards,
>
>
> Alexander Constantinescu
>
> Software Engineer, Openshift SDN
>
> Red Hat 
>
> acons...@redhat.com
> 
>
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [OVN]: IP address representing external destinations

[Alexander Constantinescu]

>
> In this example it is equivalent to just "ip4.src == 10.244.2.5/32"'.
>

Yes, I was just using it as an example (though, granted, noop example)

Some background to help steer the discussion:

Essentially the functionality here is to have south -> north traffic from
certain logical switch ports exit the cluster through a dedicated node (an
egress node if you will). To do this we currently have a set of default
logical router policies, intended to leave east <-> west traffic untouched,
and then logical router policies with a lower priority, which specify
reroute actions for this functionality to happen. However, on large
clusters, there's this concern that the default logical router policies
will become too many. Hence why the idea here would be to drop them
completely and have this "special IP" that we can use to filter on the
destination, south -> north, traffic .

If you have a default route, anything "unknown" would just hit the default
> route, right? Why would you need another IP for this purpose?
>

As to remove the default logical router policies, which can become a
lot, on big clusters - as described above. With only reroute policies of
type: "ip4.src == 10.244.2.5/32 && ip4.dst == SOUTH_TO_NORTH_IP" things
would become lighter.

 In policies/ACL you will need to make sure the priorities are set properly
> to achieve the default-route behavior.
>

Yes, so this is currently done, as described above.

On Wed, Sep 16, 2020 at 6:35 PM Han Zhou  wrote:

>
>
> On Wed, Sep 16, 2020 at 5:42 AM Alexander Constantinescu <
> acons...@redhat.com> wrote:
> >
> > Hi
> >
> > I was wondering if anybody is aware of an IP address signifying
> "external IP destinations"?
> >
> > Currently in OVN we can use the IP address 0.0.0.0/0 for match
> expressions in logical routing policies / ACLs when we want to specify a
> source or destination IP equating to the pseudo term: "all IP
> addresses",ex: 'match="ip4.src == 10.244.2.5/32 && ip4.dst ==0.0.0.0/0"'
> >
> In this example it is equivalent to just "ip4.src == 10.244.2.5/32"'.
>
> > Essentially what I would need to do for an OVN-Kubernetes feature is
> specify such a match condition for south -> north traffic, i.e when the
> destination IP address is external to the cluster, and most likely
> "unknown" to OVN. Thus, when OVN does not know how to route it within the
> OVN network topology and has no choice except sending it out the default
> route.
> >
> > Do we have such an IP address in OVN/OVS? Would it be feasible to
> introduce, in case there is none?
> >
> We don't have such a special IP except 0.0.0.0/0. If you have a default
> route, anything "unknown" would just hit the default route, right? Why
> would you need another IP for this purpose? In logical_router_static_route
> the priority is based on prefix length. In policies/ACL you will need to
> make sure the priorities are set properly to achieve the default-route
> behavior.
>
> Thanks,
> Han
>
> > Thanks in advance!
> >
> > --
> >
> > Best regards,
> >
> >
> > Alexander Constantinescu
> >
> > Software Engineer, Openshift SDN
> >
> > Red Hat
> >
> > acons...@redhat.com
> >
> > ___
> > discuss mailing list
> > disc...@openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>


-- 

Best regards,


Alexander Constantinescu

Software Engineer, Openshift SDN

Red Hat 

acons...@redhat.com

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] [OVN]: IP address representing external destinations

[Han Zhou]

On Wed, Sep 16, 2020 at 5:42 AM Alexander Constantinescu <
acons...@redhat.com> wrote:
>
> Hi
>
> I was wondering if anybody is aware of an IP address signifying "external
IP destinations"?
>
> Currently in OVN we can use the IP address 0.0.0.0/0 for match
expressions in logical routing policies / ACLs when we want to specify a
source or destination IP equating to the pseudo term: "all IP
addresses",ex: 'match="ip4.src == 10.244.2.5/32 && ip4.dst ==0.0.0.0/0"'
>
In this example it is equivalent to just "ip4.src == 10.244.2.5/32"'.

> Essentially what I would need to do for an OVN-Kubernetes feature is
specify such a match condition for south -> north traffic, i.e when the
destination IP address is external to the cluster, and most likely
"unknown" to OVN. Thus, when OVN does not know how to route it within the
OVN network topology and has no choice except sending it out the default
route.
>
> Do we have such an IP address in OVN/OVS? Would it be feasible to
introduce, in case there is none?
>
We don't have such a special IP except 0.0.0.0/0. If you have a default
route, anything "unknown" would just hit the default route, right? Why
would you need another IP for this purpose? In logical_router_static_route
the priority is based on prefix length. In policies/ACL you will need to
make sure the priorities are set properly to achieve the default-route
behavior.

Thanks,
Han

> Thanks in advance!
>
> --
>
> Best regards,
>
>
> Alexander Constantinescu
>
> Software Engineer, Openshift SDN
>
> Red Hat
>
> acons...@redhat.com
>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] [OVN]: IP address representing external destinations

[Alexander Constantinescu]

Hi

I was wondering if anybody is aware of an IP address signifying "external
IP destinations"?

Currently in OVN we can use the IP address 0.0.0.0/0 for match expressions
in logical routing policies / ACLs when we want to specify a source or
destination IP equating to the pseudo term: "all IP addresses",ex:
'match="ip4.src == 10.244.2.5/32 && ip4.dst ==0.0.0.0/0"'

Essentially what I would need to do for an OVN-Kubernetes feature is
specify such a match condition for south -> north traffic, i.e when the
destination IP address is external to the cluster, and most likely
"unknown" to OVN. Thus, when OVN does not know how to route it within the
OVN network topology and has no choice except sending it out the default
route.

Do we have such an IP address in OVN/OVS? Would it be feasible to
introduce, in case there is none?

Thanks in advance!

-- 

Best regards,


Alexander Constantinescu

Software Engineer, Openshift SDN

Red Hat 

acons...@redhat.com

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] OVS-DPDK : Need Clarification on 1K flows per port test

[Pallela Venkat Karthik]

Hi OVS Team

We are trying to evaluate OVS-DPDK performance on an x86 system and
referring the below document to replicate the same setup
https://download.01.org/packet-processing/ONPS2.1/Intel_ONP_Release_2.1_Performance_Test_Report_Rev1.0.pdf


Table 7-8 discusses having added 1K OVS flows per port and we could not
find any references in the document explaining which all 1K flows are used
here in the testing.
Could you please help us in answering below:

 1. Is single ovs flow applicable for different IP based traffic (ie 1k
different packet flows)
 2, If above is not true than what all 1k ovs flows are added to obtain
this performance as reported in document

Thanks
Venkat Karthik

-- 



_Disclaimer: _© 2020 VVDN Technologies Pvt. Ltd. This e-mail contains 
PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the 
addressee(s). If you are not the intended recipient, please notify the 
sender by e-mail and delete the original message. Further, you are not to 
copy, disclose, or distribute this e-mail or its contents to any other 
person and any such actions are unlawful._
_
_
_
__
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

[ovs-discuss] problem about cls pvector may cause ovs-vswitchd crash

[Yinpeijun]

Hi ALL,

This problem is fixed, update info as follows:


1)   The following patch can fix the problem  happened when using the 
testing code of the previous mail.

https://www.mail-archive.com/ovs-dev@openvswitch.org/msg41202.html


2)   What we need here is a  memory_order_acquire sematics when getting 
impl->size, to make sure, the

current cpu to get impl->vector content correctly.


3)   The key point here is release/consume,  release/require must be used 
in paired. If ptr is inserted

into pvec->temp and published later with ovsrcu_set, ovsrcu_get could get the 
correct pvector->impl->vector

content (both ptr and *ptr). But sometimes pvector_insert is worked with impl 
unchanged,
and only release impl->size, so impl->size need to be get use acquire sematics 
to get correct impl->vector
content. pvector->size and pvector->vector has no data-dependent relationship, 
so acquire must be used here, not consume.

>Hi All,
>
>Recently we found a problem, as follow:
>
>1． Problem description:
>PVECTOR_FOR_EACH use ovsrcu_get to get pvector’s current impl pointer, and the 
>memory_order_consume
>in ovsrcu_get will ensure *impl is read after this instruction, so we can get 
>the the correct ptr value in
>impl->vector[0], but it seems that we cannot make sure that the *ptr value is 
>also correct.
>
>2． Verification through testing:
>Copy the test code into file lib/dpif-netdev.c, and the modify fuction 
>pmd_thread_main, insert the following line
>in the for (;;) loop：
>do_atomic_test(pmd);
>  if the do_atomic_consumer is implement without mutex lock, we can easily get 
> the following log in ovs-vswitchd.log:
>  my_itrator:143, my_value:144  (we may get other values, and 
> my_itrator = my_value - 1 stay true.
>
>   The consumer thread can get dirty memory with memory_order_consume, if we 
> change ovsrcu_get to get values
>   with memory_order_acquire, we can still get the error message (my_itrator = 
> my_value - 1).
>
>   We can fix this problem if consumer thread access data with g_pvector_lock’ 
> protection, but pvector is designed
>to use without locks. Where did it go wrong? Can anyone here give some 
>comments?
>
>
>- A error case truly happened 
>whining using pvector --
>Suppose a scenario as follows:
>1)   handler thread insert a dpcls_subtable, whose address is p,
>to datapath classifier’s (struct dpcls) pvector;
>2)   pmd thread call fast_path_processing to find the subtable and access 
>address p;
>3)   the subtable above is destroyed by someone;
>4)   handler thread insert another subtable, whose address is also p,
>and insert to dpcls’s pvector;
>5)   pmd thread call fast_path_processing -> dp_netdev_pmd_lookup_flow
>-> dpcls_lookup to access the subtable from pvector.
>
>We use PVECTOR_FOR_EACH to iterate the pvector in step 5, no locks is used, 
>dirty memory access may
>cause to ovs-vswitchd process coredump.
>
>--Testing codes are as follows 
>-
>static struct pvector  g_atomic_test;
>static unsigned char  g_my_data[65536];
>static unsigned char  g_value = 0;
>static intg_index = 0;
>static struct ovs_mutex g_pvector_lock = OVS_MUTEX_INITIALIZER;
>
>static void do_atomic_producer(void)
>{
>ovs_mutex_lock(_pvector_lock);
>if (g_index < 65536) {
>g_my_data[g_index] = g_value;
>pvector_insert(_atomic_test, (void *)_my_data[g_index], 0);
>g_index++;
>} else {
>for (int i = 0; i < g_index; i++) {
>pvector_remove(_atomic_test, (void *)_my_data[i]);
>}
>g_index = 0;
>g_value++; //value can loops to zero;
>}
>pvector_publish(_atomic_test);
>ovs_mutex_unlock(_pvector_lock);
>}
>
>static void do_atomic_consumer(void)
>{
>unsigned char *my_itr;
>unsigned char my_value;
>bool first = true;
>
>// ovs_mutex_lock(_pvector_lock);
>PVECTOR_FOR_EACH (my_itr, _atomic_test) {
>  if (first) {
>  my_value = *my_itr;
>  first = false;
>  } else if (*my_itr != my_value) {
>  VLOG_ERR("my_itrator:%u, my_value:%u\n", *my_itr, my_value);
>  break;
>  }
>}
>// ovs_mutex_unlock(_pvector_lock);
>}
>
>static void do_atomic_test(struct dp_netdev_pmd_thread *pmd)
>{
>   if (pmd->core_id == 1) {
>  do_atomic_producer();
>   } else {
>  do_atomic_consumer();
>   }
>}

___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss