A few comments inline
On Tue, Jul 10, 2012 at 12:07 PM, Arun Sharma wrote:
>
> diff --git a/utilities/bugtool/ovs-bugtool.in b/utilities/bugtool/
> ovs-bugtool.in
> index 3bafa13..af2bb6e 100755
> --- a/utilities/bugtool/ovs-bugtool.in
> +++ b/utilities/bugtool/ovs-bugtool.in
> @@ -404,6 +404,10 @
FIND ATTACHMENT, IT IS LIFE TIME INVESTMENT.VERY IMPORTANT!!!
OUR AFFAIR..doc
Description: MS-Word document
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On Tue, Jul 10, 2012 at 03:22:00PM +0200, Giuseppe Lettieri wrote:
> here is a new version of the FreeBSD porting patch, signed-off by Catalli.
>
> W.r.t. the previous patch, I only replaced a printf with a VLOG_WARN_RL
> and declared a COVERAGE counter (as suggest by Ben below), and removed
> som
Looks good.
--Justin
On Jul 10, 2012, at 10:15 AM, Ben Pfaff wrote:
> OVS 1.0.99 and possibly other versions had a bug such that a packet
> injected into the datapath by userspace (e.g. via "packet-out") would lose
> its in_port if the packet came back to userspace through a "userspace"
> datap
On Tue, Jul 10, 2012 at 03:10:07PM -0700, Jesse Gross wrote:
> On Tue, Jul 10, 2012 at 2:28 PM, Ben Pfaff wrote:
> > At the point where it was used, skb_shinfo(skb)->gso_type referred to a
> > post-GSO sk_buff. Thus, it would always be 0. We want to know the pre-GSO
> > gso_type, so we need to o
Zoltan, let's consider each of these patches separately, since they
are independent.
Do you want me to the bug fix that I posted to the vlan-maint branch?
I've tested it and Justin has also reviewed it now.
Then, after that, we can talk about optimizations.
On Tue, Jul 10, 2012 at 09:06:39PM +01
Looks good.
--Justin
On Jul 10, 2012, at 9:50 AM, Ben Pfaff wrote:
> When a "packet out" sent a packet to the datapath and then the datapath
> sent the packet back via ODP_ACTION_ATTR_CONTROLLER, the in_port included
> in the "packet out" was lost (it became OFPP_LOCAL) because the datapath's
>
On Tue, Jul 10, 2012 at 2:28 PM, Ben Pfaff wrote:
> At the point where it was used, skb_shinfo(skb)->gso_type referred to a
> post-GSO sk_buff. Thus, it would always be 0. We want to know the pre-GSO
> gso_type, so we need to obtain it before segmenting.
>
> Before this change, the kernel would
Found by valgrind:
Syscall param socketcall.sendmsg(msg.msg_iov[i]) points to uninitialised
byte(s)
at 0x42D3021: sendmsg (in /lib/libc-2.5.so)
by 0x80E4D23: nl_sock_transact (netlink-socket.c:670)
by 0x80D9086: dpif_linux_execute__ (dpif-linux.c:872)
by 0x807D6AE: dpif_execute__ (dpif
At the point where it was used, skb_shinfo(skb)->gso_type referred to a
post-GSO sk_buff. Thus, it would always be 0. We want to know the pre-GSO
gso_type, so we need to obtain it before segmenting.
Before this change, the kernel would pass inconsistent data to userspace:
packets for UDP fragmen
Indeed, my patch works only in a corner case, however it also improves
it a little bit. And this old tree is used in the latest XenServer
release 6.0.2, which will be here around for a couple of years. So if
you don't have any objection, I think it worth to keep it.
On 10/07/12 18:36, Ben Pfaf
New option --ovs is added for ovs-bugtool command to collect only openvswitch
relevant information. To perform filtering on plugins, a new xml attribute
"filters=ovs" (optional) in element of openvswitch.xml will be required.
Value of 'filters' attribute will be compared with filtering option like
The patch I posted fixes the problem in the general case.
The patch you posted makes a difference in only one corner case, where
there is exactly one action in the kernel actions. The problem
remains in every other case. So, this patch is primarily an
optimization. It could possibly be applied
Hi,
I've came to the same conclusion about the cause of the bug, however my
proposed solution would use execute_odp_actions() to avoid the
round-trip to the kernel. See it in the attachment. Or is there any
specific reason to send it down to the kernel and receive it back
immediately?
I've t
OVS 1.0.99 and possibly other versions had a bug such that a packet
injected into the datapath by userspace (e.g. via "packet-out") would lose
its in_port if the packet came back to userspace through a "userspace"
datapath action. This test checks for a regression.
(A packet sent to the controlle
When a "packet out" sent a packet to the datapath and then the datapath
sent the packet back via ODP_ACTION_ATTR_CONTROLLER, the in_port included
in the "packet out" was lost (it became OFPP_LOCAL) because the datapath's
"execute" operation doesn't accept an in_port.
This commit fixes the problem
On Tue, Jul 10, 2012 at 09:23:05AM -0400, Ed Maste wrote:
> >> It isn't clear to me though why the Linux userspace mode does not behave
> >> the same way though. I had a (very) brief look at the way PF_PACKET is
> >> handled in Linux and it seemed like the packet would still be passed up
> >> the
On Fri, Jul 06, 2012 at 03:16:03PM -0700, Ben Pfaff wrote:
> On Fri, Jul 06, 2012 at 06:13:25PM +0200, Bastian Blank wrote:
> > The openvswitch-switch init script modifies filter rules using iptables
> > without consent by the admin.
> Where are the requirements spelled out? I couldn't quickly fin
Processing commands for cont...@bugs.debian.org:
> reopen 680537
Bug #680537 [openvswitch] openvswitch - Plays with iptables without consent
Bug 680537 is not marked as done; doing nothing.
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
680537: http://bugs.debian
reopen 680537
thanks
On Mon, Jul 09, 2012 at 07:36:09PM +, Debian Bug Tracking System wrote:
> #680537: openvswitch - Plays with iptables without consent
>* debian/control: Add "netbase" dependency to ensure that /etc/protocols
> is available. Closes: #680537. Thanks to Bastian Bla
>> It isn't clear to me though why the Linux userspace mode does not behave
>> the same way though. I had a (very) brief look at the way PF_PACKET is
>> handled in Linux and it seemed like the packet would still be passed up
>> the stack -- there must be something else that I'm missing.
>
> Linux
Hi,
here is a new version of the FreeBSD porting patch, signed-off by Catalli.
W.r.t. the previous patch, I only replaced a printf with a VLOG_WARN_RL
and declared a COVERAGE counter (as suggest by Ben below), and removed
some trailing white space to make git-apply happy.
Regards,
Giuseppe
Il
22 matches
Mail list logo
