On Mon, Nov 14, 2011 at 05:22:58PM -0800, Jesse Gross wrote:
> On Mon, Nov 14, 2011 at 5:22 PM, Ben Pfaff wrote:
> > In the future it is likely that our vlan support will expand to
> > include multiply tagged packets. ??When this happens, we would
> > ideally like for it to be consistent with our
Dear Sir / Madam
Wir freuen uns, Ihnen mitzuteilen, dass Sie die Summe von £ 2,000.000.00
gewonnen
GBP von American Online Promotion (Aol) 2011 Awards-Programm.
Unten angegebenen sind Ihre Identifikationsnummern:
CHARGENBEZEICHNUNG: YPA/08-43658
NUMMER: 2008234522
PIN: 1206
Wie Sie Ihre Prize
Fixed according to comments from Jesse.
--8<--cut here-->8--
Followng patch fixes bug in pop_vlan code by setting network and
transport header offsets.
pop_vlan is updated to make it in sync with newer kernel.
Signed-off-by: Pravin B Shelar
---
a
On Mon, Nov 14, 2011 at 5:22 PM, Ben Pfaff wrote:
> In the future it is likely that our vlan support will expand to
> include multiply tagged packets. When this happens, we would
> ideally like for it to be consistent with our current tagging.
>
> Currently, if we receive a packet with a partial
In the future it is likely that our vlan support will expand to
include multiply tagged packets. When this happens, we would
ideally like for it to be consistent with our current tagging.
Currently, if we receive a packet with a partial VLAN tag we will
automatically drop it in the kernel, which
On Mon, Nov 14, 2011 at 05:06:39PM -0800, Jesse Gross wrote:
> On Mon, Nov 14, 2011 at 4:32 PM, Ben Pfaff wrote:
> > In the future it is likely that our vlan support will expand to
> > include multiply tagged packets. ??When this happens, we would
> > ideally like for it to be consistent with our
This tool will be a replacement for the current ovs-vlan-test
utility. Besides from connectivity issues it will also be able
to detect performance related issues in Open vSwitch setups.
Currently it uses UDP and TCP protocols for stressing.
Issue #6976
---
Makefile.am |2
On Mon, Nov 14, 2011 at 17:00, Ben Pfaff wrote:
> On Mon, Nov 14, 2011 at 02:17:01PM -0800, Ethan Jackson wrote:
>> Why do we consider mf_fields which don't have a corresponding NXM
>> field writable? That wasn't obvious to me from reading the code.
>
> What code prompts that question?
>
This co
On Mon, Nov 14, 2011 at 4:32 PM, Ben Pfaff wrote:
> In the future it is likely that our vlan support will expand to
> include multiply tagged packets. When this happens, we would
> ideally like for it to be consistent with our current tagging.
>
> Currently, if we receive a packet with a partial
On Mon, Nov 14, 2011 at 02:17:01PM -0800, Ethan Jackson wrote:
> Why do we consider mf_fields which don't have a corresponding NXM
> field writable? That wasn't obvious to me from reading the code.
What code prompts that question?
___
dev mailing list
d
On Mon, Nov 14, 2011 at 04:50:05PM -0800, Jesse Gross wrote:
> On Mon, Nov 14, 2011 at 4:47 PM, Ben Pfaff wrote:
> > On Mon, Nov 14, 2011 at 04:45:28PM -0800, Jesse Gross wrote:
> >> On Mon, Nov 14, 2011 at 3:58 PM, Ben Pfaff wrote:
> >> > On Mon, Nov 14, 2011 at 03:33:52PM -0800, Jesse Gross wro
On Mon, Nov 14, 2011 at 4:47 PM, Ben Pfaff wrote:
> On Mon, Nov 14, 2011 at 04:45:28PM -0800, Jesse Gross wrote:
>> On Mon, Nov 14, 2011 at 3:58 PM, Ben Pfaff wrote:
>> > On Mon, Nov 14, 2011 at 03:33:52PM -0800, Jesse Gross wrote:
>> >> On Mon, Nov 14, 2011 at 3:20 PM, Ben Pfaff wrote:
>> >> >
On Mon, Nov 14, 2011 at 04:45:28PM -0800, Jesse Gross wrote:
> On Mon, Nov 14, 2011 at 3:58 PM, Ben Pfaff wrote:
> > On Mon, Nov 14, 2011 at 03:33:52PM -0800, Jesse Gross wrote:
> >> On Mon, Nov 14, 2011 at 3:20 PM, Ben Pfaff wrote:
> >> > On Mon, Nov 14, 2011 at 02:37:37PM -0800, Jesse Gross wro
On Mon, Nov 14, 2011 at 3:58 PM, Ben Pfaff wrote:
> On Mon, Nov 14, 2011 at 03:33:52PM -0800, Jesse Gross wrote:
>> On Mon, Nov 14, 2011 at 3:20 PM, Ben Pfaff wrote:
>> > On Mon, Nov 14, 2011 at 02:37:37PM -0800, Jesse Gross wrote:
>> >> On Sat, Nov 12, 2011 at 1:01 PM, Ben Pfaff wrote:
>> >> >
On Mon, Nov 14, 2011 at 3:57 PM, Jesse Gross wrote:
> On Fri, Nov 11, 2011 at 4:23 PM, Pravin B Shelar wrote:
>> diff --git a/acinclude.m4 b/acinclude.m4
>> index 648132a..458b9e5 100644
>> --- a/acinclude.m4
>> +++ b/acinclude.m4
>> @@ -238,6 +238,7 @@ AC_DEFUN([OVS_CHECK_LINUX_COMPAT], [
>> O
In the future it is likely that our vlan support will expand to
include multiply tagged packets. When this happens, we would
ideally like for it to be consistent with our current tagging.
Currently, if we receive a packet with a partial VLAN tag we will
automatically drop it in the kernel, which
On Mon, Nov 14, 2011 at 04:29:18PM -0800, Ben Pfaff wrote:
> OK, here's an incremental for that part. There's a lot of irrelevant
> churn not shown here due to the addition of ovs_action_push_vlan in
> revising patch 2, so I'll send a new copy of the patch separately.
Oops, forgot the incremental
On Mon, Nov 14, 2011 at 03:02:16PM -0800, Jesse Gross wrote:
> On Sat, Nov 12, 2011 at 1:01 PM, Ben Pfaff wrote:
> > diff --git a/datapath/README b/datapath/README
> > index 2d8a141..23a5a81 100644
> > --- a/datapath/README
> > +++ b/datapath/README
> > @@ -145,6 +145,41 @@ not understand the "vla
On Fri, Nov 11, 2011 at 4:23 PM, Pravin B Shelar wrote:
> diff --git a/acinclude.m4 b/acinclude.m4
> index 648132a..458b9e5 100644
> --- a/acinclude.m4
> +++ b/acinclude.m4
> @@ -238,6 +238,7 @@ AC_DEFUN([OVS_CHECK_LINUX_COMPAT], [
> OVS_GREP_IFELSE([$KSRC/include/linux/skbuff.h], [skb_warn_if_l
On Mon, Nov 14, 2011 at 3:20 PM, Ben Pfaff wrote:
> On Mon, Nov 14, 2011 at 02:37:37PM -0800, Jesse Gross wrote:
>> On Sat, Nov 12, 2011 at 1:01 PM, Ben Pfaff wrote:
>> > When the datapath was converted to use Netlink attributes for describing
>> > flow keys, I had a vague idea of how it could be
On Mon, Nov 14, 2011 at 02:37:37PM -0800, Jesse Gross wrote:
> On Sat, Nov 12, 2011 at 1:01 PM, Ben Pfaff wrote:
> > When the datapath was converted to use Netlink attributes for describing
> > flow keys, I had a vague idea of how it could be smoothly extensible, but
> > I didn't actually implemen
On Mon, Nov 14, 2011 at 01:04:04PM -0800, Jesse Gross wrote:
> On Sat, Nov 12, 2011 at 1:01 PM, Ben Pfaff wrote:
> > diff --git a/datapath/flow.c b/datapath/flow.c
> > index 9786c37..6caca2a 100644
> > --- a/datapath/flow.c
> > +++ b/datapath/flow.c
> > ??int flow_from_nlattrs(struct sw_flow_key *
On Sat, Nov 12, 2011 at 1:01 PM, Ben Pfaff wrote:
> diff --git a/datapath/README b/datapath/README
> index 2d8a141..23a5a81 100644
> --- a/datapath/README
> +++ b/datapath/README
> @@ -145,6 +145,41 @@ not understand the "vlan" key will not see either of
> those attributes
> and therefore will n
On Sat, Nov 12, 2011 at 1:01 PM, Ben Pfaff wrote:
> When the datapath was converted to use Netlink attributes for describing
> flow keys, I had a vague idea of how it could be smoothly extensible, but
> I didn't actually implement extensibility or carefully think it through.
> This commit adds a d
This looks good to me. Definitely seems a lot cleaner. Especially
the bitwise_copy() function, we've needed something like that for a
while.
Why do we consider mf_fields which don't have a corresponding NXM
field writable? That wasn't obvious to me from reading the code.
Ethan
On Mon, Nov 7,
v1-v2:
- Fixed memory leak.
- Removed extra blank lines.
- Removed flag, offset-stats and linkname from vport.
- Inlined skb_clear_rxhash()
- Fixed netdev-xmit()
--8<--cut here-->8--
Following patch deletes OV
On Sat, Nov 12, 2011 at 1:01 PM, Ben Pfaff wrote:
> diff --git a/datapath/flow.c b/datapath/flow.c
> index 9786c37..6caca2a 100644
> --- a/datapath/flow.c
> +++ b/datapath/flow.c
> int flow_from_nlattrs(struct sw_flow_key *swkey, int *key_lenp,
> const struct nlattr *attr)
[.
Looks good to me.
I think the flow_set_vlan_vid() function could possibly use a comment.
In particular, it may be worth noting that it clears the pcp value
when vid is OFP_VLAN_NONE. I don't feel strongly about it though.
Ethan
On Mon, Nov 7, 2011 at 21:50, Ben Pfaff wrote:
> ---
> lib/flow.
Looks good.
Ethan
On Mon, Nov 7, 2011 at 21:50, Ben Pfaff wrote:
> NXM breaks ICMP into v4 and v6. An upcoming commit will drop all of the
> NXM specific data in favor of mf_field, and so at that point we need to
> have a separate mf_field for each NXM field. So, this commit splits
> ICMP into
On Mon, Nov 14, 2011 at 10:06:18AM -0800, Jesse Gross wrote:
> On Sat, Nov 12, 2011 at 12:35 PM, Ben Pfaff wrote:
> > I've been thinking that we could just use 0 instead of a special
> > constant for "none" in the ethernet type case, by the way. ??There's no
> > particular reason to use 0x5ff as w
The Netlink code in the Linux kernel has been willing to choose unique
Netlink pids for userspace sockets since at least 2.4.36 and probably
earlier. There's no value in choosing them ourselves.
This simplifies the code and eliminates the possibility of exhausting our
supply of Netlink PIDs.
---
On Sat, Nov 12, 2011 at 12:35 PM, Ben Pfaff wrote:
> I've been thinking that we could just use 0 instead of a special
> constant for "none" in the ethernet type case, by the way. There's no
> particular reason to use 0x5ff as we do in userspace.
I think that's probably true, you'd have to transl
On Mon, Nov 14, 2011 at 06:27:05PM +0900, Jari Sundell wrote:
> This patch fixes an issue where dst_field->n_bytes == 1 and
> src_value_bytes == 2 causing a segfault.
This doesn't look right at all. AFAICT your patch causes the whole
value to be thrown away instead of displayed.
Can you give an
On Mon, Nov 14, 2011 at 05:41:28PM +0900, Simon Horman wrote:
> The assert() statement in unixctl_command_register() implies that it is
> intended to be idempotent but inserting the same name and callback twice
> would fail because:
>
> * The callback is not stored directly in the hash, rather it
This patch fixes an issue where dst_field->n_bytes == 1 and
src_value_bytes == 2 causing a segfault.
Jari Sundell
---
diff --git a/lib/learn.c b/lib/learn.c
index 9f95a13..9fea40a 100644
--- a/lib/learn.c
+++ b/lib/learn.c
@@ -622,8 +622,10 @@ learn_format(const struct nx_action_learn *learn,
st
The assert() statement in unixctl_command_register() implies that it is
intended to be idempotent but inserting the same name and callback twice
would fail because:
* The callback is not stored directly in the hash, rather it the
cb element of a struct unixctl_command which is stored in the hash
36 matches
Mail list logo
