Hello Dear
I am Joy Dickson, I have things of very important i will
like to discuss with you ,Kindly reply back immediately for more about
me
Thanks Yours
Joy___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On Fri, 2011-11-18 at 15:12 -0800, Jesse Gross wrote:
> Open vSwitch is a multilayer Ethernet switch targeted at virtualized
> environments. In addition to supporting a variety of features
> expected in a traditional hardware switch, it enables fine-grained
> programmatic extension and flow-based
Reading your website - it seems you indicate the code to be portable
across other platforms. That is a noble reason - but i dont think
it is good enough a reason in my opinion to have your own
replicated infrastructure on top of Linux.
cheers,
jamal
On Mon, 2011-11-21 at 07:20 -0500, jamal wrot
On Sat, Nov 19, 2011 at 10:20:24AM -0800, Jesse Gross wrote:
> We currently use a seqcount to prevent reading partial 64-bit stats
> on 32-bit CPUs. u64_stats_sync uses the same logic but elides it on
> 64-bit and uniprocessor machines. This improves performance (primarily
> on non-x86 architectu
On Sat, Nov 19, 2011 at 02:11:47PM -0800, Jesse Gross wrote:
> We currently use a specialized version of what amounts to
> genl_dereference() to protect the flow table. This prepares to
> propose genl_dereference() upstream and uses it instead of our
> version.
>
> Signed-off-by: Jesse Gross
Ac
On Sat, Nov 19, 2011 at 02:11:48PM -0800, Jesse Gross wrote:
> We currently have a wrapper to protect the datapath ports array.
> However, this can lead to confusion over exactly what lock is
> protecting the access (either RTNL or RCU). This removes the
> wrapper in favor of directly accessing th
On Sat, Nov 19, 2011 at 02:40:13PM -0800, Jesse Gross wrote:
> We currently notify for port deletions in the namespace of the device
> that was deleted. In general this should be initial namespace because
> that's the only place where we look but it's possible that the device
> was moved after bei
On Mon, Nov 21, 2011 at 10:00 AM, Ben Pfaff wrote:
> On Sat, Nov 19, 2011 at 02:11:48PM -0800, Jesse Gross wrote:
>> We currently have a wrapper to protect the datapath ports array.
>> However, this can lead to confusion over exactly what lock is
>> protecting the access (either RTNL or RCU). Thi
On Mon, Nov 21, 2011 at 10:09:47AM -0800, Jesse Gross wrote:
> On Mon, Nov 21, 2011 at 10:00 AM, Ben Pfaff wrote:
> > On Sat, Nov 19, 2011 at 02:11:48PM -0800, Jesse Gross wrote:
> >> We currently have a wrapper to protect the datapath ports array.
> >> However, this can lead to confusion over exa
On Sat, Nov 19, 2011 at 02:40:14PM -0800, Jesse Gross wrote:
> Signed-off-by: Jesse Gross
Acked-by: Ben Pfaff
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On Mon, Nov 21, 2011 at 10:09 AM, Ben Pfaff wrote:
> On Sat, Nov 19, 2011 at 02:40:13PM -0800, Jesse Gross wrote:
>> We currently notify for port deletions in the namespace of the device
>> that was deleted. In general this should be initial namespace because
>> that's the only place where we loo
On Mon, Nov 21, 2011 at 9:49 AM, Ben Pfaff wrote:
> On Sat, Nov 19, 2011 at 10:20:24AM -0800, Jesse Gross wrote:
>> We currently use a seqcount to prevent reading partial 64-bit stats
>> on 32-bit CPUs. u64_stats_sync uses the same logic but elides it on
>> 64-bit and uniprocessor machines. This
On Mon, Nov 21, 2011 at 10:16:01AM -0800, Jesse Gross wrote:
> On Mon, Nov 21, 2011 at 10:09 AM, Ben Pfaff wrote:
> > On Sat, Nov 19, 2011 at 02:40:13PM -0800, Jesse Gross wrote:
> >> We currently notify for port deletions in the namespace of the device
> >> that was deleted. ??In general this sho
According to the specification the enqueue action should refer to
"a valid physical port", or OFPP_IN_PORT. It would be strange to
attach a queueing discipline to the local port, but I see no reason
to restrict it.
---
DESIGN | 10 ++
lib/ofp-util.c |3 ++-
2 files changed,
On Mon, Nov 21, 2011 at 10:30:56AM -0800, Ethan Jackson wrote:
> According to the specification the enqueue action should refer to
> "a valid physical port", or OFPP_IN_PORT. It would be strange to
> attach a queueing discipline to the local port, but I see no reason
> to restrict it.
Looks good,
On Mon, Nov 21, 2011 at 10:29 AM, Ben Pfaff wrote:
> On Mon, Nov 21, 2011 at 10:16:01AM -0800, Jesse Gross wrote:
>> On Mon, Nov 21, 2011 at 10:09 AM, Ben Pfaff wrote:
>> > On Sat, Nov 19, 2011 at 02:40:13PM -0800, Jesse Gross wrote:
>> >> We currently notify for port deletions in the namespace o
---
utilities/.gitignore |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/utilities/.gitignore b/utilities/.gitignore
index 30b135c..ecc4d5f 100644
--- a/utilities/.gitignore
+++ b/utilities/.gitignore
@@ -21,6 +21,8 @@
/ovs-pki
/ovs-pki-cgi
/ovs-pki.8
+/ovs-test
+/ovs-
Thanks, I've merged this.
On Mon, Nov 21, 2011 at 10:32, Ben Pfaff wrote:
> On Mon, Nov 21, 2011 at 10:30:56AM -0800, Ethan Jackson wrote:
>> According to the specification the enqueue action should refer to
>> "a valid physical port", or OFPP_IN_PORT. It would be strange to
>> attach a queueing
On Mon, Nov 21, 2011 at 10:39:23AM -0800, Ethan Jackson wrote:
> --- a/utilities/.gitignore
> +++ b/utilities/.gitignore
> @@ -21,6 +21,8 @@
> /ovs-pki
> /ovs-pki-cgi
> /ovs-pki.8
> +/ovs-test
> +/ovs-test.8
> /ovs-tcpundump
> /ovs-tcpundump.1
> /ovs-vlan-bug-workaround
Looks good, thanks.
_
Looks good. It seems that I forgot to add my generated files to .gitignore.
Thanks,
Ansis
On Mon, Nov 21, 2011 at 10:39 AM, Ethan Jackson wrote:
> ---
> utilities/.gitignore |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/utilities/.gitignore b/utilities/.gitigno
I often forget too, because I use separate source and build
directories.
On Mon, Nov 21, 2011 at 10:44:39AM -0800, Ansis Atteka wrote:
> Looks good. It seems that I forgot to add my generated files to .gitignore.
>
> Thanks,
> Ansis
>
> On Mon, Nov 21, 2011 at 10:39 AM, Ethan Jackson wrote:
>
Yah don't worry about it, people forget to update gitignore all the
time, not a big deal.
Ethan
On Mon, Nov 21, 2011 at 10:46, Ben Pfaff wrote:
> I often forget too, because I use separate source and build
> directories.
>
> On Mon, Nov 21, 2011 at 10:44:39AM -0800, Ansis Atteka wrote:
>> Looks
Currently, there is no way to disable forwarding on an OpenFlow
port from the command line. This patch adds support for the
OFPPC_NO_FWD flag to the ovs-ofctl utility.
---
utilities/ovs-ofctl.8.in |7 +++
utilities/ovs-ofctl.c|5 +
2 files changed, 12 insertions(+), 0 deletion
This patch adds basic tests to ofproto-dpif which verify that
output and flood actions respect the relevant OFPPC flags, and do
not loop back to the in_port.
---
tests/ofproto-dpif.at | 48
1 files changed, 48 insertions(+), 0 deletions(-)
diff -
On Mon, Nov 21, 2011 at 11:14:20AM -0800, Ethan Jackson wrote:
> Currently, there is no way to disable forwarding on an OpenFlow
> port from the command line. This patch adds support for the
> OFPPC_NO_FWD flag to the ovs-ofctl utility.
Looks good, thanks.
On Mon, Nov 21, 2011 at 11:14:21AM -0800, Ethan Jackson wrote:
> +AT_SETUP([ofproto-dpif - output/flood flags])
> +dnl This test assumes that OpenFlow port numbers are allocated in order
> +dnl starting from one.
Do we actually reliably implement that, though? I'd expect the ports
to get added in
Here's an incremental.
---
tests/ofproto-dpif.at | 24 +---
1 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/tests/ofproto-dpif.at b/tests/ofproto-dpif.at
index db2dccd..13c6fd7 100644
--- a/tests/ofproto-dpif.at
+++ b/tests/ofproto-dpif.at
@@ -64,7 +64,10 @@
On Mon, Nov 21, 2011 at 12:49:51PM -0800, Ethan Jackson wrote:
> Here's an incremental.
The incremental looks OK.
Another question comes to mind, though. Why don't the OpenFlow
enqueue actions generate datapath actions to set the queue id?
___
dev mail
> Another question comes to mind, though. Why don't the OpenFlow
> enqueue actions generate datapath actions to set the queue id?
I think it's because the relevant queue doesn't actually exist, so it
falls back to an output action. To fix this, I would need to add
queues to the netdev-dummy modu
On Mon, Nov 21, 2011 at 01:12:38PM -0800, Ethan Jackson wrote:
> > Another question comes to mind, though. ?Why don't the OpenFlow
> > enqueue actions generate datapath actions to set the queue id?
>
> I think it's because the relevant queue doesn't actually exist, so it
> falls back to an output
From: Pravin B Shelar
Open vSwitch uses Generic Netlink interface for communication
between userspace and kernel module. genl_notify() is used
for sending notification back to userspace.
genl_notify() is analogous to rtnl_notify() but uses genl_sock
instead of rtnl.
Signed-off-by: Pravin B Shel
This series of patches proposes the Open vSwitch kernel components for
upstream. Open vSwitch has existed as a separate project for several
years and we now believe it to be mature enough for inclusion. The
actual functionality is described more fully in the commit that adds
the kernel code.
The
From: Pravin B Shelar
Open vSwitch uses genl_mutex locking to protect datapath
data-structures like flow-table, flow-actions. Following patch adds
lockdep_genl_is_held() which is used for rcu annotation to prove
locking.
Signed-off-by: Pravin B Shelar
Signed-off-by: Jesse Gross
---
v2: Unchang
This adds rcu_dereference_genl and genl_dereference, which are genl
variants of the RTNL functions to enforce proper locking with lockdep
and sparse.
Signed-off-by: Jesse Gross
---
v2: New patch.
---
include/linux/genetlink.h | 21 +
1 files changed, 21 insertions(+), 0 del
From: Pravin B Shelar
Open vSwitch needs this function for vlan handling.
Signed-off-by: Pravin B Shelar
Signed-off-by: Jesse Gross
---
v2: Unchanged.
---
include/linux/if_vlan.h | 34 ++
net/8021q/vlan_core.c | 33 -
2 fil
The dpif-netdev implementation disallowed enqueue actions because
it did not support conversion from OVS 'queue_id' to dpif
'priority'. For testing purposes, this patch allows queues which
translate into NOOPs.
---
lib/dpif-netdev.c | 10 +-
tests/ofproto-dpif.at |4 ++--
2 file
On Mon, Nov 21, 2011 at 01:39:26PM -0800, Ethan Jackson wrote:
> The dpif-netdev implementation disallowed enqueue actions because
> it did not support conversion from OVS 'queue_id' to dpif
> 'priority'. For testing purposes, this patch allows queues which
> translate into NOOPs.
Awesome, thank
Thanks, I've merged this.
Ethan
On Mon, Nov 21, 2011 at 13:41, Ben Pfaff wrote:
> On Mon, Nov 21, 2011 at 01:39:26PM -0800, Ethan Jackson wrote:
>> The dpif-netdev implementation disallowed enqueue actions because
>> it did not support conversion from OVS 'queue_id' to dpif
>> 'priority'. For t
On Mon, 21 Nov 2011 13:30:29 -0800
Jesse Gross wrote:
> +/**
> + * vport_record_error - indicate device error to generic stats layer
> + *
> + * @vport: vport that encountered the error
> + * @err_type: one of enum vport_err_type types to indicate the error type
> + *
> + * If using the vport g
There are lots of new global symbols created by this module.
Since C has no namespaces, a kernel module needs to in general
stick to one prefix and naming convention.
$ nm openvswitch.ko | grep -v ' U ' | grep -v ' [btrd] '
D __this_module
28c6 T cleanup_module
00
Thanks, I added some comments.
On Mon, Nov 14, 2011 at 12:50:33PM -0800, Ethan Jackson wrote:
> 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
On Mon, Nov 14, 2011 at 05:02:22PM -0800, Ethan Jackson wrote:
> 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
Sounds fine to me.
Ethan
On Mon, Nov 21, 2011 at 14:44, Ben Pfaff wrote:
> On Mon, Nov 14, 2011 at 05:02:22PM -0800, Ethan Jackson wrote:
>> 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 whi
On Mon, Nov 21, 2011 at 1:59 PM, Stephen Hemminger
wrote:
> On Mon, 21 Nov 2011 13:30:29 -0800
> Jesse Gross wrote:
>
>> +/**
>> + * vport_record_error - indicate device error to generic stats layer
>> + *
>> + * @vport: vport that encountered the error
>> + * @err_type: one of enum vport_err_t
On Mon, Nov 21, 2011 at 2:12 PM, Stephen Hemminger
wrote:
> There are lots of new global symbols created by this module.
> Since C has no namespaces, a kernel module needs to in general
> stick to one prefix and naming convention.
That's a good point. Thanks, I'll fix it.
___
On Mon, 21 Nov 2011 15:18:43 -0800
Jesse Gross wrote:
> On Mon, Nov 21, 2011 at 1:59 PM, Stephen Hemminger
> wrote:
> > On Mon, 21 Nov 2011 13:30:29 -0800
> > Jesse Gross wrote:
> >
> >> +/**
> >> + * vport_record_error - indicate device error to generic stats layer
> >> + *
> >> + * @vport:
Hallo lieve,
Ik ben Nancy, een vrouw. Ik ben een mooie liefdevolle en goed uitziende jonge
dame, maar ben geïnteresseerd in het kennen u in persoon. Kunnen we vrienden?,
schrijf me op mijn privé e-mail zodat kan ik mijn foto's naar u sturen, alsook
invoering van mezelf goed aan u.
Jouwe Nancy...
2011/11/22 Stephen Hemminger :
> On Mon, 21 Nov 2011 15:18:43 -0800
> Jesse Gross wrote:
>
>> On Mon, Nov 21, 2011 at 1:59 PM, Stephen Hemminger
>> wrote:
>> > On Mon, 21 Nov 2011 13:30:29 -0800
>> > Jesse Gross wrote:
>> >
>> >> +/**
>> >> + * vport_record_error - indicate device error to gen
One more comment...
Shouldn't this device be using netdev_increment_features() like bridging and
bonding
to have the features of the pseudo device reflect those of the underlying
hardware.
This would make the device have TSO only if underlying hardware supported it,
etc.
_
49 matches
Mail list logo
