From: Jiri Benc <jbenc@redhat.com>
To: Amir Vadai <amir@vadai.me>
Cc: Stephen Hemminger <stephen@networkplumber.org>,
netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
Or Gerlitz <ogerlitz@mellanox.com>,
Hadar Har-Zion <hadarh@mellanox.com>,
Jiri Pirko <jiri@mellanox.com>
Subject: Re: [PATCH iproute2 V3 3/3] tc/act_tunnel: Introduce ip tunnel action
Date: Wed, 30 Nov 2016 15:44:53 +0100 [thread overview]
Message-ID: <20161130154453.3394b3f2@griffin> (raw)
In-Reply-To: <20161130073840.5269-4-amir@vadai.me>
On Wed, 30 Nov 2016 09:38:40 +0200, Amir Vadai wrote:
> +The
> +.I UNSET
> +mode is optional - even without using it, the metadata information will be
> +released automatically when packet processing will be finished.
> +.IR UNSET
> +function could be used in cases when traffic is forwarded between two tunnels,
> +where the metadata from the first tunnel will be used for encapsulation done by
> +the second tunnel.
This looks good.
> +It must be used for offloaded filters, such that hardware drivers can
> +realize they need to program the HW to do decapsulation.
However, this is wrong. The hardware offloading must be transparent.
The same configuration that works when processed in software must work
in hardware if the hardware has the necessary capabilities. Requiring
the user to alter the configuration to accommodate hardware
peculiarities is not acceptable.
Or maybe I'm misunderstanding what you mean here. In which case it's
not documented properly :-)
> +.IR SET
> +mode requires the source and destination ip
> +.I ADDRESS
> +and the tunnel key id
> +.I KEY_ID
> +which will be used by the ip tunnel shared device to create the tunnel header. The
> +.B tunnel_key
> +action is useful only in combination with a
> +.B mirred redirect
> +action to a shared IP tunnel device which will use the metadata (for
> +.I SET
> +) and unset the metadata created by it (for
> +.I UNSET
> +).
> +
> +.SH OPTIONS
> +.TP
> +.B unset
> +Decapsulation mode, no further arguments allowed. This function is not
> +mandatory and might be used only in some specific use cases.
This is NOT decapsulation. The packet is decapsulated at this point in
any case, whether or not set/unset or whatever is used. These actions
are only and solely about metadata associated with the packet. The
actual encapsulation and decapsulation happens at the target netdevice.
Calling this "decapsulation" is wrong. And if it's implemented as such
in your hardware offloading, then it's doubly wrong as it doesn't match
software processing and hence you must not do that and you must change
that.
> +.TP
> +.B set
> +Encapsulation mode. Requires
Likewise, this is not encapsulation. It just sets metadata.
Jiri
next prev parent reply other threads:[~2016-11-30 14:44 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-30 7:38 [PATCH iproute2 V3 0/3] tc: Support for ip tunnel metadata set/unset/classify Amir Vadai
2016-11-30 7:38 ` [PATCH iproute2 V3 1/3] libnetlink: Introduce rta_getattr_be*() Amir Vadai
2016-11-30 7:38 ` [PATCH iproute2 V3 2/3] tc/cls_flower: Classify packet in ip tunnels Amir Vadai
2016-11-30 7:38 ` [PATCH iproute2 V3 3/3] tc/act_tunnel: Introduce ip tunnel action Amir Vadai
2016-11-30 14:44 ` Jiri Benc [this message]
2016-12-01 9:57 ` Amir Vadai
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161130154453.3394b3f2@griffin \
--to=jbenc@redhat.com \
--cc=amir@vadai.me \
--cc=davem@davemloft.net \
--cc=hadarh@mellanox.com \
--cc=jiri@mellanox.com \
--cc=netdev@vger.kernel.org \
--cc=ogerlitz@mellanox.com \
--cc=stephen@networkplumber.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox