There are only two symbols in actions.h. Compatibility function
is moved to compat.h and execute_actions() declaration is moved
to datapath.h
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
The function flow_metadata_from_nlattrs() is very restrictive
about the ordering and type of metadata attributes that it receives.
This patch will change flow_metadata_from_nlattrs() behavior by
ignoring attributes that it does not understand and allowing them
to be passed in arbitrary order.
Issue #8167
Signed-off-by: Ansis Atteka <aatteka@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
A few of the recently added fields in struct sw_flow_key had
comments that weren't properly aligned.
Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
IPv6 uses the term "traffic class" for what IPv4 calls
"type-of-service". This commit renames the the "ipv6_tos" field to
"ipv6_tclass" in the "ovs-key_ipv6" struct to be more consistent with
the IPv6 terminology.
Suggested-by: Jesse Gross <jesse@nicira.com>
Signed-off-by: Justin Pettit <jpettit@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
Add support matching the IPv4 TTL and IPv6 hop limit fields. This
commit also adds support for modifying the IPv4 TTL. Modifying the IPv6
hop limit isn't currently supported, since we don't support modifying
IPv6 headers.
We will likely want to change the user-space interface, since basic
matching and setting the TTL are not generally useful. We will probably
want the ability to match on extraordinary events (such as TTL of 0 or 1)
and a decrement action.
Feature #8024
Signed-off-by: Justin Pettit <jpettit@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
This will be useful later when we add support for matching the ECN bits
within the TOS field.
Signed-off-by: Justin Pettit <jpettit@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
When updating the IP TOS field, the checksum was not properly calculated
on little endian systems. This commit fixes the issue.
Signed-off-by: Justin Pettit <jpettit@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
Currently multicast and unicast tunnel ports share port pools but
there's no overlap between the two in the lookup, which means that
we can do a lookup that has no chance of ever finding a port. This
separates them out.
Suggested-by: Ben Pfaff <blp@nicira.com>
Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
It's possible to have an incoming packet that matches both a unicast
and multicast tunnel if the source address corresponds to the remote_ip
of a unicast tunnel and the destination is multicast. Currently this
will match the multicast tunnel but in reality the unicast tunnel
should probably be considered more specific. This is actually a
common situation in protocols that use a combination of multicast
for flooding and unicast for responses.
Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
The interfaces related to tunneling aren't finalized enough to be
sent upstream but we also still want to retain them in the OVS
repository. Since userspace should be compatible with both versions
of the kernel, this renumbers the tunnel interfaces to high numbers
so that we can continue to add new interfaces without conflict.
Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
Many of the function in vport.c are simply pass throughs to their
underlying vport implementation and, of these, many are used only
for bridge compatibility code. This allows users of these functions
to directly call through the ops structure, reducing boilerplate code
and keeping more of the compatibility code together.
Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
Now that most fix function logic (like sFlow) has been moved to
userspace, the vport member of OVS_CB is no longer used by anything,
so drop it.
Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
From 2.6.39 kernel netdev features are set using set_features and
fix_features APIs. Since internal-dev does not need any special
checks on setting feature, there is no need to define set_features
or fix_features. Only hw_features needs to be set to features that
are supported by internal-dev.
Following patch does same and drops discrete offload setting ops for
newer kernel.
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
Bug #7772
We currently set netdev->flags to IFF_BROADCAST | IFF_MULTICAST
but this is unnecessary because it's already done by ether_setup().
Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
This checks whether key_len is not zero but we set the key length
at the beginning of the function, so I don't see this as a useful
check.
Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
The kernel can parse IPv6, so if it receives a flow with an IPv6
EtherType then it expects to get IPv6 information as well.
Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
Following patch adds skb-priority to flow key. So userspace will know
what was priority when packet arrived and we can remove the pop/reset
priority action. It's no longer necessary to have a special action for
pop that is based on the kernel remembering original skb->priority.
Userspace can just emit a set priority action with the original value.
Since the priority field is a match field with just a normal set action,
we can convert it into the new model for actions that are based on
matches.
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
Bug #7715
This doesn't matter for any of the current users of ACTION, nor do I expect
it to matter, but it seems like a good idea nonetheless.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
Something like this, on two separate vswitches, works to try it out:
route add -net 224.0.0.0 netmask 240.0.0.0 dev eth0
ovs-vsctl \
-- add-port br0 gre0 \
-- set interface gre0 type=gre options:remote_ip=224.0.0.1
Runtime tested on Linux 3.0, build tested on Linux 2.6.18, both i386.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
Currently we hard code the versions of our GENL families to 1 but it's
nicer to have symbolic constants.
Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
Commit 4edb9ae90e "datapath: Refactor
actions in terms of match fields." introduced a spurious warning
because the compiler thinks a value might not have been assigned to
'err'. In practice this can't happen because we've already validated
the actions.
CC: Pravin B Shelar <pshelar@nicira.com>
Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Pravin B Shelar <pshelar@nicira.com>
I originally meant just to fix the use of kfree_skb() instead of
consume_skb() on the success path, but then I realized that the failure
path returned an skb that it had just freed.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
Until now, OVS has handled IP fragments more awkwardly than necessary. It
has not been possible to match on L4 headers, even in fragments with offset
0 where they are actually present. This means that there was no way to
implement ACLs that treat, say, different TCP ports differently, on
fragmented traffic; instead, all decisions for fragment forwarding had to
be made on the basis of L2 and L3 headers alone.
This commit improves the situation significantly. It is still not possible
to match on L4 headers in fragments with nonzero offset, because that
information is simply not present in such fragments, but this commit adds
the ability to match on L4 headers for fragments with zero offset. This
means that it becomes possible to implement ACLs that drop such "first
fragments" on the basis of L4 headers. In practice, that effectively
blocks even fragmented traffic on an L4 basis, because the receiving IP
stack cannot reassemble a full packet when the first fragment is missing.
This commit works by adding a new "fragment type" to the kernel flow match
and making it available through OpenFlow as a new NXM field named
NXM_NX_IP_FRAG. Because OpenFlow 1.0 explicitly says that the L4 fields
are always 0 for IP fragments, it adds a new OpenFlow fragment handling
mode that fills in the L4 fields for "first fragments". It also enhances
ovs-ofctl to allow users to configure this new fragment handling mode and
to parse the new field.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Bug #7557.
Almost all current actions can be expressed in the form of
push/pop/set <field>, where field is one of the match fields. We can
create three base actions and take a field. This has both a nice
symmetry and avoids inconsistencies where we can match on the vlan
TPID but not set it.
Following patch converts all actions to this new format.
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
Bug #7115
From 3.1 kernel, struct dst_entry no longer has direct ref to hh_cache.
Following patch handles this case.
Signed-off-by: Pravin Shelar <pshelar@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
Following patch cleanup hh_cache access by avoiding hh pointer fetching
most of time. Now hh is read and checked at beginning of function. All
hh->hh_len access are done inside hh_lock.
This is required cleanup for next patch which adds support for kernel
3.1.
Suggested-by: Jesse Gross <jesse@nicira.com>
Signed-off-by: Pravin Shelar <pshelar@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
Without this commit, a pair of commands like
ovs-dpctl add-if br0 gre0,type=gre,remote_ip=192.168.5.2,csum=true
ovs-dpctl set-if br0 gre0,csum=false
would result in a csum of "true" for gre0, that is, the second command
would silently have no effect. This could also happen when the key data
(such as remote_ip) changed but the port hash just happened to have the
same value.
This also fixes a small kernel memory leak in this case.
An upcoming commit implements the "ovs-dpctl set-if" command mentioned
above.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
Until now this has just silently failed, but it seems to me like we should
actively reject it.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
Linux 3.1 adds a flag to check whether it's OK for shared skbs to
be transmitted on devices. This generally isn't a problem for
hardware devices but software devices such as OVS that hold state
in the skb need to clear the flag, which is enabled by default.
Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
Linux 3.1 drops the symbol HAVE_NET_DEVICE_OPS that lets us know
whether struct netdev_ops is present. As a result, we need to
replace it with an explicit version check.
Signed-off-by: Jesse Gross <jesse@nicira.com>
Acked-by: Ben Pfaff <blp@nicira.com>
It's only called when we want a best-match now, so there's no need to pass
in any flags that indicate the desired type of match.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
Without this change, the following commands succeed:
# ovs-dpctl add-if br1 gre1,type=gre,remote_ip=1.2.3.4,local_ip=2.3.4.5
# ovs-dpctl add-if br1 gre0,type=gre,remote_ip=1.2.3.4
but if they are run in the opposite order, they fail with:
ovs-dpctl: adding gre1 to br1 failed (File exists)
This fixes the problem.
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
This increases consistency with the OVS_ACTION_ATTR_USERSPACE action, which
also requires an explicit pid.
Suggested-by: Jesse Gross <jesse@nicira.com>
Signed-off-by: Ben Pfaff <blp@nicira.com>
Acked-by: Jesse Gross <jesse@nicira.com>
