On Fri, May 20, 2016 at 11:20:04AM +0200, Jiri Benc wrote:
> On Fri, 20 May 2016 18:12:05 +0900, Simon Horman wrote:
[...]
> > 3. With regards to the mirroring part of your question, I need to check
> >on that and possibly its broken. But my thinking is that a mirroring
> >vport would reg
On Fri, 20 May 2016 18:12:05 +0900, Simon Horman wrote:
> 1. push_eth adds an Ethernet header with all-zero addresses and
>the Ethernet type as determined from skb->protocol which is in
>turn determined by the tunnel header (we have discussed that
>bit before).
>
>In principle it i
On Fri, May 20, 2016 at 10:39:39AM +0200, Jiri Benc wrote:
> On Fri, 20 May 2016 17:16:13 +0900, Simon Horman wrote:
> > My understanding is that currently OvS handles access ports using a
> > push_vlan action.
>
> When needed (i.e. when the packet goes to a non-access port), yes.
>
> > And that
On Fri, 20 May 2016 17:16:13 +0900, Simon Horman wrote:
> My understanding is that currently OvS handles access ports using a
> push_vlan action.
When needed (i.e. when the packet goes to a non-access port), yes.
> And that this patch set in conjunction with its
> user-space counterpart should en
On Fri, May 20, 2016 at 05:11:23PM +0900, Simon Horman wrote:
> On Fri, May 20, 2016 at 10:00:28AM +0200, Jiri Benc wrote:
> > On Fri, 20 May 2016 14:29:01 +0900, Simon Horman wrote:
> > > The second option does seem rather tempting although I'm not sure
> > > that it actually plays out in the acce
On Fri, May 20, 2016 at 10:00:28AM +0200, Jiri Benc wrote:
> On Fri, 20 May 2016 14:29:01 +0900, Simon Horman wrote:
> > The second option does seem rather tempting although I'm not sure
> > that it actually plays out in the access-port scenario at this time.
>
> We support gre ports to be access
On Fri, 20 May 2016 14:29:01 +0900, Simon Horman wrote:
> The second option does seem rather tempting although I'm not sure
> that it actually plays out in the access-port scenario at this time.
We support gre ports to be access ports currently. With conversion to
ipgre, this needs to continue wor
Hi Jiri,
On Tue, May 17, 2016 at 04:32:50PM +0200, Jiri Benc wrote:
> Looking through the patchset again, this time more deeply. Sorry for
> the delay.
No need to be sorry, good things take time.
> On Wed, 4 May 2016 16:36:30 +0900, Simon Horman wrote:
> > +struct ovs_action_push_eth {
> > +
On Tue, May 17, 2016 at 04:43:20PM +0200, Jiri Benc wrote:
> On Thu, 12 May 2016 07:46:52 +0900, Simon Horman wrote:
> > If we can live with a bogus skb->mac_len value that is sufficient for
> > ovs_flow_key_extract.() and set correctly by key_extract() (which happens
> > anyway) we could do someth
On Thu, 12 May 2016 07:46:52 +0900, Simon Horman wrote:
> If we can live with a bogus skb->mac_len value that is sufficient for
> ovs_flow_key_extract.() and set correctly by key_extract() (which happens
> anyway) we could do something like this:
>
> } else if (vport->dev->type == ARPHRD_NON
Looking through the patchset again, this time more deeply. Sorry for
the delay.
On Wed, 4 May 2016 16:36:30 +0900, Simon Horman wrote:
> +struct ovs_action_push_eth {
> + struct ovs_key_ethernet addresses;
> + __be16 eth_type;
Extra spaces.
> +static int pop_eth(struct sk_buff *skb, s
On Wed, May 11, 2016 at 04:09:28PM +0200, Jiri Benc wrote:
> On Wed, 11 May 2016 12:06:35 +0900, Simon Horman wrote:
> > Is this close to what you had in mind?
>
> Yes but see below.
>
> > @@ -739,17 +729,17 @@ int ovs_flow_key_extract(const struct ip_tunnel_info
> > *tun_info,
> > key->phy.
On Wed, 11 May 2016 12:06:35 +0900, Simon Horman wrote:
> Is this close to what you had in mind?
Yes but see below.
> @@ -739,17 +729,17 @@ int ovs_flow_key_extract(const struct ip_tunnel_info
> *tun_info,
> key->phy.skb_mark = skb->mark;
> ovs_ct_fill_key(skb, key);
> key->ovs
On Wed, 11 May 2016 12:28:14 +0900, Simon Horman wrote:
> I think that at this stage I would prefer to prohibit push_eth() acting
> on a packet which already has an ethernet header. Indeed that is what
> my patch-set already does in its modifications of __ovs_nla_copy_actions().
>
> The reason tha
On Wed, 11 May 2016 10:50:12 +0900, Simon Horman wrote:
> On Tue, May 10, 2016 at 02:01:06PM +0200, Jiri Benc wrote:
> > We have two options here:
> >
> > 1. As for metadata tunnels all the info is in metadata_dst and we
> >don't need the IP/GRE header for anything, we can make the ipgre
> >
Hi Jiri,
On Tue, May 10, 2016 at 02:06:18PM +0200, Jiri Benc wrote:
> On Mon, 9 May 2016 17:18:20 +0900, Simon Horman wrote:
> > On Fri, May 06, 2016 at 11:35:04AM +0200, Jiri Benc wrote:
> > > In addition, we should check whether mac_len > 0 and in such case,
> > > change skb->protocol to ETH_P_T
Hi Jiri,
On Wed, May 11, 2016 at 10:50:09AM +0900, Simon Horman wrote:
[...]
> > > Its possible that I've overlooked something but as things stand I think
> > > things look like this:
> > >
> > > * ovs_flow_key_extract() keys off dev->type and skb->protocol.
> > > * ovs_flow_key_extract() calls
Hi Jiri,
On Tue, May 10, 2016 at 02:01:06PM +0200, Jiri Benc wrote:
> On Mon, 9 May 2016 17:04:22 +0900, Simon Horman wrote:
> > It seems to be caused by the following:
> >
> > 1. __ipgre_rcv() calls skb_pop_mac_header() which
> >sets skb->mac_header to the skb->network_header.
> >
> > 2. __
Please do not top post.
On Tue, 10 May 2016 00:16:36 +, Yang, Yi Y wrote:
> I think it is still necessary to keep eth_type in push_eth action, for
> the classifier case, it will push_nsh then push_eth for the original
> frame, this will need to set eth_type to 0x894f by push_eth, otherwise
> p
On Mon, 9 May 2016 17:18:20 +0900, Simon Horman wrote:
> On Fri, May 06, 2016 at 11:35:04AM +0200, Jiri Benc wrote:
> > In addition, we should check whether mac_len > 0 and in such case,
> > change skb->protocol to ETH_P_TEB first (and store that value in the
> > pushed eth header).
> >
> > Simila
On Mon, 9 May 2016 17:04:22 +0900, Simon Horman wrote:
> It seems to be caused by the following:
>
> 1. __ipgre_rcv() calls skb_pop_mac_header() which
>sets skb->mac_header to the skb->network_header.
>
> 2. __ipgre_rcv() then calls ip_tunnel_rcv() which calls
>skb_reset_network_header().
o:dev-boun...@openvswitch.org] On Behalf Of Simon Horman
Sent: Monday, May 09, 2016 4:18 PM
To: Jiri Benc
Cc: dev@openvswitch.org; net...@vger.kernel.org
Subject: Re: [ovs-dev] [PATCH v9 net-next 4/7] openvswitch: add layer 3
flow/port support
On Fri, May 06, 2016 at 11:35:04AM +0200, Jiri Benc
On Fri, May 06, 2016 at 11:35:04AM +0200, Jiri Benc wrote:
> On Wed, 4 May 2016 16:36:30 +0900, Simon Horman wrote:
> > +static int push_eth(struct sk_buff *skb, struct sw_flow_key *key,
> > + const struct ovs_action_push_eth *ethh)
> > +{
> > + int err;
> > +
> > + /* De-acceler
On Fri, May 06, 2016 at 11:25:14AM +0200, Jiri Benc wrote:
> On Fri, 6 May 2016 14:57:07 +0900, Simon Horman wrote:
> > On Thu, May 05, 2016 at 10:37:08AM -0700, pravin shelar wrote:
> > > On transmit side you are using mac_len to detect l3 packet, why not do
> > > same while extracting the key?
>
On Wed, 4 May 2016 16:36:30 +0900, Simon Horman wrote:
> +static int push_eth(struct sk_buff *skb, struct sw_flow_key *key,
> + const struct ovs_action_push_eth *ethh)
> +{
> + int err;
> +
> + /* De-accelerate any hardware accelerated VLAN tag added to a previous
> +
On Fri, 6 May 2016 14:57:07 +0900, Simon Horman wrote:
> On Thu, May 05, 2016 at 10:37:08AM -0700, pravin shelar wrote:
> > On transmit side you are using mac_len to detect l3 packet, why not do
> > same while extracting the key?
I agree. The skb should be self-contained, i.e. it should be obvious
[CC Jiri Benc]
On Thu, May 05, 2016 at 10:37:08AM -0700, pravin shelar wrote:
> On Wed, May 4, 2016 at 12:36 AM, Simon Horman
> wrote:
> > From: Lorand Jakab
> >
> > Implementation of the pop_eth and push_eth actions in the kernel, and
> > layer 3 flow support.
> >
> > This doesn't actually do a
On Wed, May 4, 2016 at 12:36 AM, Simon Horman
wrote:
> From: Lorand Jakab
>
> Implementation of the pop_eth and push_eth actions in the kernel, and
> layer 3 flow support.
>
> This doesn't actually do anything yet as no layer 2 tunnel ports are
> supported yet. The original patch by Lorand was ag
From: Lorand Jakab
Implementation of the pop_eth and push_eth actions in the kernel, and
layer 3 flow support.
This doesn't actually do anything yet as no layer 2 tunnel ports are
supported yet. The original patch by Lorand was against the Open vSwtich
tree which has L2 LISP tunnels but that is
29 matches
Mail list logo
