lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5584609C.5020802@cumulusnetworks.com>
Date:	Fri, 19 Jun 2015 11:34:04 -0700
From:	roopa <roopa@...ulusnetworks.com>
To:	Robert Shearman <rshearma@...cade.com>
CC:	ebiederm@...ssion.com, tgraf@...g.ch, davem@...emloft.net,
	netdev@...r.kernel.org
Subject: Re: [PATCH net-next RFC v2 1/3] lwt: infrastructure to support light
 weight tunnels

On 6/19/15, 10:25 AM, Robert Shearman wrote:
> n 19/06/15 16:14, roopa wrote:
>> Today lwtunnel_skb_lwstate is called from lwtunnel_output which is only
>> called from ipv4 code.
>> And my ipv6 variant code was supposed to have a 6 suffix. something like
>> lwtunnel_output6.
>> Or to be more explicit i will probably have variants of the output and
>> skb handling functions like,
>> lwtunnel_output_ipv4 and lwtunnel_output_ipv6.
>
> Do you intend for these functions to be used by netdevices to support 
> the vxlan use case?
>
> If so, then how will the netdevice know which one of the two to call? 
> Will there have to be a netdevice for ipv4 and a netdevice for ipv6?
>
> If not, could you outline how you intend for it to be implemented?

In the netdevice case, this output function is not called atall. It 
should just follow the existing netdevice the route is pointing to.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ