On Mon, Sep 04, 2017 at 06:42:16PM +0800, Jiri Benc wrote:
> On Mon, 4 Sep 2017 16:00:05 +0800, Yang, Yi wrote:
> > how can we know next push_nsh uses the same nsh header as previous
> > one?
>
> We store the prepopulated header together with the action.
>
I checked source code but can't find whe
On Mon, Sep 04, 2017 at 08:57:44PM +0800, Jiri Benc wrote:
> On Mon, 4 Sep 2017 20:09:07 +0800, Yang, Yi wrote:
> > So we must do many changes if we want to break this assumption.
>
> We may do as many changes as we want to. This is uAPI we're talking
> about and we need to get it right since the
On Mon, Sep 04, 2017 at 07:22:26PM +0800, Hannes Frederic Sowa wrote:
> Hello,
>
> "Yang, Yi" writes:
>
> > On Wed, Aug 30, 2017 at 05:53:27PM +0800, Hannes Frederic Sowa wrote:
> >> Hello,
> >>
> >> Yi Yang writes:
> >>
> >> [...]
> >>
> >> > +struct ovs_key_nsh {
> >> > +u8 flags;
INVITATION WORKSHOP PROPERTY :
"STRATEGI INVESTASI MENCETAK PROFIT MINIMAL 100% DALAM 1 TAHUN DARI
PROPERTY"
100% EDUKASI & LANGSUNG PRAKTEK..!!
MATERI WORKSHOP:
1. OUTLOOK & FUNDAMENTAL BISNIS INVESTASI PROPERTI 2017
2. ANDA AKAN DIAJARKAN CARA MENILAI PROSPEK SEBUAH LOKASI & PROPERTI
3.
Hi, All
I'm just learning ipv6. When I go through ovs code about ipv6 normal
forwarding, I find 2 possible "bugs". Could you explain some for me? Thanks.
1. In fucntion "xlate_normal". when mcast snooping is on, ipv6 neighbor
discover packet, whose dest mac is "33:33:**", is proccessed in
mcast_s
On Fri, 2017-08-18 at 21:27 +, Mark Michelson wrote:
> On Fri, Aug 18, 2017 at 4:09 PM Ben Pfaff wrote:
>
> > On Mon, Aug 14, 2017 at 09:54:10PM +, Mark Michelson wrote:
> > > I debugged the problem further and I now have figured out that the
> >
> > problem
> > > has to do with a form f
> On Mon, 4 Sep 2017 14:07:45 +, Jan Scheurich wrote:
> > Then perhaps I misunderstood your comment. I thought you didn't like that
> > the
> > SET_MASKED action wrapped OVS_KEY_ATTR_NSH which in itself was nested.
> > I was aiming to avoid this by lifting the two components of the NSH header
On Mon, 4 Sep 2017 14:07:45 +, Jan Scheurich wrote:
> Then perhaps I misunderstood your comment. I thought you didn't like that the
> SET_MASKED action wrapped OVS_KEY_ATTR_NSH which in itself was nested.
> I was aiming to avoid this by lifting the two components of the NSH header
> component
Applied to master and branch-2.8.
Alin.
> -Original Message-
> From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-
> boun...@openvswitch.org] On Behalf Of Shashank Ram
> Sent: Wednesday, August 30, 2017 11:29 PM
> To: Sairam Venugopal ; d...@openvswitch.org
> Subject: Re: [ovs-dev] [PA
Acked-by: Alin Gabriel Serdean
> -Original Message-
> From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-
> boun...@openvswitch.org] On Behalf Of Shashank Ram
> Sent: Wednesday, August 30, 2017 11:29 PM
> To: Sairam Venugopal ; d...@openvswitch.org
> Subject: Re: [ovs-dev] [PATCH v2] d
Thanks, applied on master and branch-2.8.
Alin.
> -Original Message-
> From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-
> boun...@openvswitch.org] On Behalf Of Anand Kumar
> Sent: Saturday, August 26, 2017 2:21 AM
> To: Alin Gabriel Serdean ; d...@openvswitch.org
> Subject: Re: [ovs
I applied this on master and branch-2.8.
Thanks,
Alin.
> -Original Message-
> From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-
> boun...@openvswitch.org] On Behalf Of Anand Kumar
> Sent: Thursday, August 31, 2017 2:04 AM
> To: d...@openvswitch.org
> Subject: [ovs-dev] [PATCH] datapa
> > So is what you are suggesting the following?
> >
> > For matching:
> > OVS_KEY_ATTR_NSH_BASE_HEADERmandatory
> > OVS_KEY_ATTR_NSH_MD1_CONTEXToptional, in case MDTYPE == MD1
>
> This needs to be:
>
> OVS_KEY_ATTR_NSH
> OVS_KEY_ATTR_NSH_BASE_HEADER
>
I also tested with an Openstack environment with two nodes.
Acked-by: Alin Gabriel Serdean
> -Original Message-
> From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-
> boun...@openvswitch.org] On Behalf Of Anand Kumar
> Sent: Thursday, August 31, 2017 2:04 AM
> To: d...@openvswitch.o
On Mon, 4 Sep 2017 12:57:15 +, Jan Scheurich wrote:
> So is what you are suggesting the following?
>
> For matching:
> OVS_KEY_ATTR_NSH_BASE_HEADER mandatory
> OVS_KEY_ATTR_NSH_MD1_CONTEXT optional, in case MDTYPE == MD1
This needs to be:
OVS_KEY_ATTR_NSH
OVS_KEY_AT
On Wed, 30 Aug 2017 20:39:12 +0800, Yi Yang wrote:
> +enum ovs_nsh_key_attr {
> + OVS_NSH_KEY_ATTR_BASE, /* struct ovs_nsh_key_base. */
> + OVS_NSH_KEY_ATTR_MD1, /* struct ovs_nsh_key_md1. */
> + OVS_NSH_KEY_ATTR_MD2, /* variable-length octets for MD type 2. */
> + __OVS_NSH_KE
Now that Patchwork 2.0 is out, folks can start to take advantage of some
of the new features that it offers. Chief among these is series support,
which is only exposed via the web UI and new REST API and which, in
turn, necessitates using git-pw rather than pwclient. As such, this tool
is slightly
> On Mon, 4 Sep 2017 16:00:05 +0800, Yang, Yi wrote:
> > I think we have had similiar discussion about this, the issue is we have
> > no way to handle both MD type 1 and MD type 2 by using a common flow key
> > struct.
> >
> > So we have to do so, there is miniflow to handle such issue in
> > user
On Mon, 4 Sep 2017 20:09:07 +0800, Yang, Yi wrote:
> So we must do many changes if we want to break this assumption.
We may do as many changes as we want to. This is uAPI we're talking
about and we need to get it right since the beginning. Sure, it may
mean that some user space programs need some
On Mon, Sep 04, 2017 at 12:42:16PM +0200, Jiri Benc wrote:
> On Mon, 4 Sep 2017 16:00:05 +0800, Yang, Yi wrote:
> > I think we have had similiar discussion about this, the issue is we have
> > no way to handle both MD type 1 and MD type 2 by using a common flow key
> > struct.
> >
> > So we have
> >> Does it makes sense to keep the context headers as part of the flow?
> >> What is the reasoning behind it? With mdtype 2 headers this might either
> >> not work very well or will increase sw_flow_key size causing slowdowns
> >> for all protocols.
> >
> > For userspace, miniflow can handle such
Hello,
Jan Scheurich writes:
>> >> >> Does it makes sense to keep the context headers as part of the flow?
>> >> >> What is the reasoning behind it? With mdtype 2 headers this might
>> >> >> either not work very well or will increase sw_flow_key size causing
>> >> >> slowdowns for all protocols.
Hello,
"Yang, Yi" writes:
> On Wed, Aug 30, 2017 at 05:53:27PM +0800, Hannes Frederic Sowa wrote:
>> Hello,
>>
>> Yi Yang writes:
>>
>> [...]
>>
>> > +struct ovs_key_nsh {
>> > + u8 flags;
>> > + u8 ttl;
>> > + u8 mdtype;
>> > + u8 np;
>> > + __be32 path_hdr;
>> > + __be32 context[NSH_
On Mon, 4 Sep 2017 16:00:05 +0800, Yang, Yi wrote:
> I think we have had similiar discussion about this, the issue is we have
> no way to handle both MD type 1 and MD type 2 by using a common flow key
> struct.
>
> So we have to do so, there is miniflow to handle such issue in
> userspace, but ke
Thanks for your testing!
Thanks
Zhenyu Gao
2017-09-03 18:46 GMT+08:00 Stokes, Ian :
> OK,
>
>
>
> In my own testing I’m seeing the same behavior with a tap interface
> pinging to a bridge with a DPDK device. As such I think this should be ok.
>
>
>
> Acked-by: ian.sto...@intel.com
>
>
>
> Ian
>
> >> >> Does it makes sense to keep the context headers as part of the flow?
> >> >> What is the reasoning behind it? With mdtype 2 headers this might
> >> >> either not work very well or will increase sw_flow_key size causing
> >> >> slowdowns for all protocols.
> >> > [Mooney, Sean K]
> >> > Havi
Hello Neil,
NAT can be configured as range of addresses, so it is impossible to
Get this information before actual translation happens.
In general I don't see any problem with creating egress action
as it works in ipfix as default configuration along ingress
action. When it comes to caching
On Thu, Aug 31, 2017 at 06:45:16PM +0800, Jiri Benc wrote:
> > + mask->context[i]);
> > + }
> > + memcpy(flow_key->nsh.context, nsh->md1.context,
> > + sizeof(nsh->md1.context));
>
> Do you follow the discussion that Hannes Sowa
28 matches
Mail list logo