Hi,
On Tue, 23 Aug 2016 19:21:41 +0300 Amir Vadai wrote:
> On Tue, Aug 23, 2016 at 08:37:07AM -0400, Jamal Hadi Salim wrote:
> >
> > The noun "ip tunnel" is a little misleading. Unless you can use
> > this for other types of tunnels (ipip, etc). If this is specific
> > for just vxlan and metadat
On Tue, Aug 23, 2016 at 08:37:07AM -0400, Jamal Hadi Salim wrote:
> On 16-08-22 10:38 AM, Amir Vadai wrote:
> > This action could be used before redirecting packets to a shared tunnel
> > device, or when redirecting packets arriving from a such a device
> >
> > The action will release the metadata
On Tue, Aug 23, 2016 at 05:33:49PM +0200, Jiri Benc wrote:
> On Tue, 23 Aug 2016 18:28:05 +0300, Amir Vadai wrote:
> > On Mon, Aug 22, 2016 at 08:51:37PM +0200, Jiri Benc wrote:
> > > 2. We may run into problems like tx path seeing the metadata_dst that
> > >it should not see. This means either
On Tue, 23 Aug 2016 19:05:37 +0300, Amir Vadai wrote:
> It is already there - user can use act_mirred and redirect skb's with
> metadata since shared tunnel devices introduced.
You're right, I haven't thought of that.
> The only thing that was added here, is to enable the user to drop the
> metad
On Tue, 23 Aug 2016 18:28:05 +0300, Amir Vadai wrote:
> On Mon, Aug 22, 2016 at 08:51:37PM +0200, Jiri Benc wrote:
> > 2. We may run into problems like tx path seeing the metadata_dst that
> >it should not see. This means either this situation or such
> >configuration must be prevented some
On Mon, Aug 22, 2016 at 08:51:37PM +0200, Jiri Benc wrote:
> On Mon, 22 Aug 2016 21:15:41 +0300, Or Gerlitz wrote:
> > Jiri B > I understand the motivation for the decap action. However, what
> > would
> > Jiri B > happen if someone does not include it?
> >
> > The MD set by the (say) vxlan devic
On 16-08-22 10:38 AM, Amir Vadai wrote:
This action could be used before redirecting packets to a shared tunnel
device, or when redirecting packets arriving from a such a device
The action will release the metadata created by the tunnel device
(decap), or set the metadata with the specified valu
On Mon, Aug 22, 2016 at 08:57:06PM +0300, Shmulik Ladkani wrote:
> Hi,
>
> On Mon, 22 Aug 2016 17:38:34 +0300 Amir Vadai wrote:
> > +static struct metadata_dst *iptunnel_alloc(struct tcf_iptunnel *t,
> > + __be32 saddr, __be32 daddr,
> > +
On Mon, 22 Aug 2016 21:15:41 +0300, Or Gerlitz wrote:
> Jiri B > I understand the motivation for the decap action. However, what would
> Jiri B > happen if someone does not include it?
>
> The MD set by the (say) vxlan device will not be "consumed" (cleared)
> and would be keep travelling with the
On Mon, Aug 22, 2016 at 5:38 PM, Amir Vadai wrote:
> This action could be used before redirecting packets to a shared tunnel
> device, or when redirecting packets arriving from a such a device
nit, add period
> The action will release the metadata created by the tunnel device
> (decap), or set
Hi,
On Mon, 22 Aug 2016 17:38:34 +0300 Amir Vadai wrote:
> +static struct metadata_dst *iptunnel_alloc(struct tcf_iptunnel *t,
> +__be32 saddr, __be32 daddr,
> +__be64 key_id)
> +{
> + struct ip_tunnel_info *tun_i
On Mon, 22 Aug 2016 17:38:34 +0300, Amir Vadai wrote:
> This action could be used before redirecting packets to a shared tunnel
> device, or when redirecting packets arriving from a such a device
>
> The action will release the metadata created by the tunnel device
> (decap), or set the metadata w
This action could be used before redirecting packets to a shared tunnel
device, or when redirecting packets arriving from a such a device
The action will release the metadata created by the tunnel device
(decap), or set the metadata with the specified values for encap
operation.
For example, the
13 matches
Mail list logo
