[ovs-discuss] switch flow self-insertion

Fri Jul 6 22:51:04 UTC 2018

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 <blp at ovn.org> 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 <blp at ovn.org> 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 <blp at ovn.org> 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 <blp at ovn.org> 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 <blp at ovn.org> napisał(a):
> > > > > > > > >
> > > > > > > > > > Which hash are you talking about?  OVS has lots of hashes
> > all
> > > > over.
> > > > > > > > > >
> > > > > > > > > > On Thu, Jul 05, 2018 at 07:46:57PM +0200, Grzegorz wrote:
> > > > > > > > > > > Hi Ben,
> > > > > > > > > > > You're absolutely right. Thank you! Now I understand how
> > it
> > > > > > works.
> > > > > > > > > > >
> > > > > > > > > > > So having such the knowledge I have another question. In
> > > > order to
> > > > > > > > > > implement
> > > > > > > > > > > other part of our mechanism I need to place in kernel
> > space
> > > > only
> > > > > > > > flows
> > > > > > > > > > that
> > > > > > > > > > > for which mach (hash) is done based only on MPLS label.
> > If I
> > > > > > correct
> > > > > > > > > > > understand how OVS worsk, the hash is done based on all
> > > > header
> > > > > > > > fields.
> > > > > > > > > > So I
> > > > > > > > > > > need to put somewhere in code simple if statement, i.e.:
> > > > > > > > > > >
> > > > > > > > > > > if (packet is tagged with MPLS)
> > > > > > > > > > >    hash = label_number
> > > > > > > > > > > else
> > > > > > > > > > >    proceed_regular_hash_calculation
> > > > > > > > > > >
> > > > > > > > > > > Could someone point me a place where such the statement
> > > > should be
> > > > > > > > placed
> > > > > > > > > > in
> > > > > > > > > > > the code? Thank you in advance.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > czw., 5 lip 2018 o 18:56 Ben Pfaff <blp at ovn.org>
> > napisał(a):
> > > > > > > > > > >
> > > > > > > > > > > > On Thu, Jul 05, 2018 at 10:32:23AM +0200, Grzegorz
> > wrote:
> > > > > > > > > > > > > We want to make some OSV code modification in order
> > to
> > > > obtain
> > > > > > > > > > > > fuctionality
> > > > > > > > > > > > > desribed in https://arxiv.org/pdf/1805.07993.pdf
> > > > > > > > > > > > > Strictly speaking wa want to implement the part
> > related
> > > > to
> > > > > > > > Figure 4
> > > > > > > > > > on
> > > > > > > > > > > > page
> > > > > > > > > > > > > 10. In shortcut, the proposed mechanism uses 2 flow
> > > > tables
> > > > > > > > (Detailed
> > > > > > > > > > and
> > > > > > > > > > > > > Coarse Flow Table, DTF and CFT). The first stores
> > exact
> > > > > > 5-tuple
> > > > > > > > > > match,
> > > > > > > > > > > > when
> > > > > > > > > > > > > the latter cotains match based on only destination
> > > > network.
> > > > > > When
> > > > > > > > a
> > > > > > > > > > flow
> > > > > > > > > > > > is
> > > > > > > > > > > > > missed in DFT, the second table is looked up. When
> > the
> > > > match
> > > > > > is
> > > > > > > > > > found in
> > > > > > > > > > > > > CFT, a packated is proccessed according to this much
> > and
> > > > > > > > > > simultaneously
> > > > > > > > > > > > > switch prepares a new match based on this packet
> > 5-tuple
> > > > and
> > > > > > > > acctions
> > > > > > > > > > > > > copied from CFT. Such flow is inserted by switch
> > into DFT
> > > > > > itself.
> > > > > > > > > > > >
> > > > > > > > > > > > This sounds like what OVS already does with its
> > multiple
> > > > > > layers of
> > > > > > > > > > > > caches, or possibly with connection tracking.  What's
> > new
> > > > about
> > > > > > > > your
> > > > > > > > > > > > design?
> > > > > > > > > > > >
> > > > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >