Re: [ovs-discuss] ofproto-dpif-upcall: reg. udpif_revalidator thread

2018-07-08 Thread Ethan J. Jackson
Gosh, this is some old code.  On my read, the `n_flows > 2000` is redundant.  
My best guess is the line below where it sets a floor on the flow_limit of 1000 
was supposed to catch it.  Really that floor should either be 2000, or the 
check in the if statement should be `n_flows > 1000`.

All of that said, I really don't see the point of the `n_flows > 2000` check at 
all.  I'm a bit worried there was some reason for it that I can't quite 
remember, but if I was fixing this myself, I would just remove it.,

Ethan J. Jackson
ejj.sh ( http://ejj.sh )

On Fri, Jul 06, 2018 at 10:52 AM, Ben Pfaff < b...@ovn.org > wrote:

> 
> 
> 
> On Fri, Jul 06, 2018 at 05:22:55PM +, Vishal Deep Ajmera wrote:
> 
> 
>> 
>>> 
>>> 
>>> At first glance it looks like you're correct, but this code was added in
>>> 2013 with the following commit and hasn't changed since, so I wonder
>>> whether we're missing something important. Ethan, you wrote this code, do
>>> you have any thoughts?
>>> 
>>> 
>>> 
>>> commit e79a6c833e0d72370951d6f8841098103cbb0b2d
>>> Author: Ethan J. Jackson < ejj@ eecs. berkeley. edu ( e...@eecs.berkeley.edu
>>> ) > Tue Sep 24 13:39:56 2013
>>> Committer: Ethan J. Jackson < ejj@ eecs. berkeley. edu (
>>> e...@eecs.berkeley.edu ) > Thu Dec 19 13:27:23 2013
>>> 
>>> 
>>> 
>>> ofproto: Handle flow installation and eviction in upcall.
>>> 
>>> 
>>> 
>>> This patch moves flow installation and eviction from ofproto-dpif and the
>>> main thread, into ofproto-dpif-upcall. This performs significantly better
>>> (approximately 2x TCP_CRR improvement), and allows ovs-vswitchd to
>>> maintain significantly larger datapath flow tables. On top of that, it
>>> significantly simplifies the code, retiring "struct facet" and friends.
>>> 
>>> 
>>> 
>>> Signed-off-by: Ethan Jackson < ethan@ nicira. com ( et...@nicira.com ) >
>>> Acked-by: Ben Pfaff < blp@ nicira. com ( b...@nicira.com ) >
>>> 
>>> 
>> 
>> 
>> 
>> Thanks Ben for looking into this issue. Should I send a formal patch for
>> review by removing this check (n_flows > 2000) ?
>> 
>> 
> 
> 
> 
> Let's see what Ethan has to say first.
> 
> 
>___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss


[ovs-discuss] ovs-appctl to monitor HVs sb connection status

2018-07-08 Thread aginwala
Hi:

As per discussions in past OVN meetings regarding ovn monitoring stand
point, need some clarity from design perspective. I am thinking of below
approaches:

1. Can we implement something like ovs-appctl -t  chassis-conn/list
that will show all HVs stats (connected/non-connected)?

2. or  on individual HVs using ovs-appctl -t ovn-controller
chassis-conn/list ?

For now, we can manually verify with couple of ways on individual HV using
netstat, controller logs, etc. However, it makes sense to have some feature
to quickly get a glimpse of whats connected and what not in a large env
setup having many HV counts instead of checking individual chassis.

Hence, need some agreement/suggestions before starting the implementation
along with some other alternatives if in mind.



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


Re: [ovs-discuss] switch flow self-insertion

2018-07-08 Thread Grzegorz
We want to aggregate flows using MPLS labeling

sob., 7 lip 2018 o 00:51 Ben Pfaff  napisał(a):

> An MPLS packet, from an OVS datapath perspective, only has a few fields
> anyway:
>
> - Ethernet source and destination.
> - Ethertype is always the MPLS ethertype.
> - Optional VLAN tag(s).
> - MPLS labels?
>
> What's the value of leaving out those other fields?
>
> On Sat, Jul 07, 2018 at 12:39:02AM +0200, Grzegorz wrote:
> > OK, so I suppose for my purposes I need two separate hash tables in EMC:
> > one regular and one just for MPLS matching.
> > Or may I procced like this?
> > if (packet with MPLS label!=0)
> >   zeroes all fileds except MPLS header and compute hash
> > else
> >   regular hash
> >
> > pt., 6 lip 2018 o 23:54 Ben Pfaff  napisał(a):
> >
> > > Leaving data that will be used in a key comparison out of the hash will
> > > also cause hash collisions.
> > >
> > > On Thu, Jul 05, 2018 at 11:31:06PM +0200, Grzegorz wrote:
> > > > Ok, I agree. We don't want to change a hash function but only the
> input
> > > to
> > > > it, i.e., we want that hash will be computed based only on label
> number
> > > in
> > > > our case in microflow cache. Of course for such the hash the label
> number
> > > > can be used itself as a hash value.
> > > >
> > > > Regarding proposed mechanism, let say that we have some class of
> flows
> > > that
> > > > should be treated in network in same way, i.e., that are directed to
> the
> > > > same point in the network.  Please consider such the simple network:
> > > >
> > > > n1---|
> > > >  |--n3---n4
> > > > n2---|
> > > >
> > > > (n1 -> n3, n2->n3, n3->4 if picture is not clear)
> > > >
> > > > Let's consider a situation when n1 and n2 want to send a packet to
> n4. So
> > > > n1 stores one flow in microcache, n2 stores one flow in microcache,
> n3
> > > > stores 2 flows in its microcache and same n4. If n1 and n2 (or rather
> > > host
> > > > connected to them) will generate 3 different flows directed to n4,
> the
> > > > number of flows in each node (switch) will be tripled.
> > > > But if all nodes (controlled by OF controller) will use same label to
> > > reach
> > > > a particular node in the network, the number of flows will be as
> follows
> > > > (in case of 3 flows originated in n1 and n2):
> > > > n1: 3 flows, matches based on 5tuple, all with same actions, i.e.
> > > MPLS=400,
> > > > out=1
> > > > n2: 3 flows, matches based on 5tuple, all with same actions, i.e.
> > > MPLS=400,
> > > > out=1
> > > > n3: 1 flow, match based on mpls label and proper action to send out
> to
> > > > proper interface.
> > > > This is a simple case, but when a network is complicated number of
> flows
> > > in
> > > > core (in this case n3) switches may be reduced.
> > > >
> > > > This approach is used simultaneously with multipath transmission
> > > approach.
> > > > Please look into figure 2 and section IIB on the page 6 of
> > > > https://arxiv.org/pdf/1805.07993.pdf for some explanation.
> > > >
> > > >
> > > >
> > > > czw., 5 lip 2018 o 22:59 Ben Pfaff  napisał(a):
> > > >
> > > > > Typically, changing a hash function in this way will only increase
> the
> > > > > number of hash collisions without reducing the number of hash table
> > > > > entries.
> > > > >
> > > > > On Thu, Jul 05, 2018 at 10:49:03PM +0200, Grzegorz wrote:
> > > > > > Sure, but we want to examine how a number of flows is reduced
> when
> > > > > proposed
> > > > > > mechanism is implemented. If we use what is now available in
> ovs, it
> > > will
> > > > > > still generate thousands of flows (hashes) in Exact Match Cache.
> > > Please
> > > > > > correct me if I'm wrong
> > > > > >
> > > > > > czw., 5 lip 2018 o 22:41 Ben Pfaff  napisał(a):
> > > > > >
> > > > > > > You can match on MPLS flows without needing to modify OVS's
> kernel
> > > flow
> > > > > > > table structure.  Why do you want to modify it?
> > > > > > >
> > > > > > > On Thu, Jul 05, 2018 at 09:25:05PM +0200, Grzegorz wrote:
> > > > > > > > The goal is to minimize number of flows (aggregate them) in
> the
> > > core
> > > > > of
> > > > > > > > network using some labeling. In our case MPLS is proposed
> but any
> > > > > other
> > > > > > > > technique allowing for labeling may be used, e.g. VLANs.
> This is
> > > > > part of
> > > > > > > s
> > > > > > > > bigger idea. Details are presented in paper
> > > > > > > > https://arxiv.org/pdf/1805.07993.pdf
> > > > > > > >
> > > > > > > > czw., 5 lip 2018 o 21:15 Ben Pfaff  napisał(a):
> > > > > > > >
> > > > > > > > > It's an odd change.  What's the goal?
> > > > > > > > >
> > > > > > > > > On Thu, Jul 05, 2018 at 08:27:08PM +0200, Grzegorz wrote:
> > > > > > > > > > I'm taking about hash based on which flow table is
> looked up
> > > in
> > > > > > > kernel
> > > > > > > > > data
> > > > > > > > > > path.
> > > > > > > > > >
> > > > > > > > > > czw., 5 lip 2018 o 20:20 Ben Pfaff 
> napisał(a):
> > > > > > > > > >
> > > > > > > > > > >