So that means when a new flow comes its written in both classifier and
netdev?
Thanks for the help!
Bibrak
On Thu, Sep 8, 2011 at 7:55 PM, Ben Pfaff wrote:
> The tables have different purposes. A flow in the classifier is an
> OpenFlow flow that may contain wildcards. A flow in the datapath
>
There is no need to have vport interface for MTU as linux net-dev-ioctl
can be used to get/set MTU for linux device.
Following patch removes kernel vport interface for MTU and fixes
netdev->get_mtu by linux net-dev ioctl. netdev->set_mtu is also added so
that MTU set can be done from OVS userspace.
> Any patches included in the original series that aren't been listed below were
> either merged or dropped.
"aren't been". Slick english.
Ethan
>
> The following patches are completely new and need review:
> bridge: ovsdb_idl_omit_alert() on additional columns.
> bridge: Write CFM changes m
That's very clear. Thank you.
On Thu, Sep 08, 2011 at 06:10:48PM -0700, Ethan Jackson wrote:
> I added the following paragraph to the documentation. I'll be
> resending this whole series in a bit.
>
> According to the 802.1ag specification. Each Maintenance Point should
> be co
I'm glad to hear that it was dropped. I didn't have a specific
objection, so I didn't say anything about it, but there was something
about it that I didn't like.
On Thu, Sep 08, 2011 at 05:23:14PM -0700, Ethan Jackson wrote:
> I've decided to drop this patch as it's no longer necessary. I'll be
I missed this in last vport iflink patch.
As IFLA_LINK is not be passed in netlink msg there is no need to
allocate space for it.
Signed-off-by: Pravin B Shelar
---
datapath/datapath.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/datapath/datapath.c b/datapath/dat
A controller may want to know which MPIDs are reachable from an
interface configured with CFM. This patch regularly writes this
information to the database.
Bug #7014.
---
lib/cfm.c | 23 +++
lib/cfm.h |2 ++
ofproto/ofproto-dpif.c
802.1ag only allows for MPIDs in the range [1, 8191]. This is
restrictive enough to make assignment of MPIDs to instances of OVS
awkward. This patch allows six byte MPIDs when running in extended
mode.
Bug #7014.
---
lib/cfm.c | 52 +++-
The standard CFM protocol only allows a handful of transmission
rates. This is particularly problematic if you want to support a
transmission rate slower than 100 ms and faster than 1000 ms.
This patch allows arbitrary transmission rates (between 1 ms and
65535 ms). It does this by commandeering
The new extended mode introduced in this patch will be used for
features which break wire compatibility with 802.1ag compliant
implementations.
Bug #7014.
---
lib/cfm.c | 18 --
lib/cfm.h |3 ++-
ofproto/ofproto-dpif.c |2 +-
vswitchd/bridge.c
According to the 802.1ag specification, users should be able to
configure the CFM module with a list of remote endpoints with which
the local endpoint should have connectivity. Commit 93b8df3853
"cfm: Remove Maintenance_Point and Monitor tables." changed the
behavior so that only one remote endpoi
---
lib/cfm.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/lib/cfm.c b/lib/cfm.c
index dc55d4b..2a79d63 100644
--- a/lib/cfm.c
+++ b/lib/cfm.c
@@ -67,6 +67,7 @@ struct cfm {
uint16_t mpid;
bool fault;/* Indicates connectivity fault. */
This patch no longer rate limits database updates due to CFM
changes. Due to recent changes, the fault status of CFM only
changes once per 3.5 tx_interval seconds. There doesn't seem to be
a good reason to add an additional rate limit on top of this.
---
vswitchd/bridge.c | 36
---
vswitchd/bridge.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/vswitchd/bridge.c b/vswitchd/bridge.c
index 00157e1..bcb1fc6 100644
--- a/vswitchd/bridge.c
+++ b/vswitchd/bridge.c
@@ -1269,6 +1269,8 @@ iface_refresh_cfm_stats(struct iface *iface)
if (fault >= 0
The bridge owns the lacp_current and cfm_fault columns and should
not be alerted when they change.
---
vswitchd/bridge.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/vswitchd/bridge.c b/vswitchd/bridge.c
index 2bfd926..ada82ff 100644
--- a/vswitchd/bridge.c
+++ b/vswit
Any patches included in the original series that aren't been listed below were
either merged or dropped.
The following patches are completely new and need review:
bridge: ovsdb_idl_omit_alert() on additional columns.
bridge: Write CFM changes more aggressively.
The following patches changed s
I added the following paragraph to the documentation. I'll be
resending this whole series in a bit.
According to the 802.1ag specification. Each Maintenance Point should
be configured out-of-band with a list of Remote Maintenance Points it
should have connectivity to. Op
Thanks for the review. I've renamed it "unexpected_recv".
Ethan
On Thu, Sep 8, 2011 at 13:37, Ben Pfaff wrote:
> Is "xrecv" standard terminology for LACP? Otherwise I'd prefer
> something a bit more spelled out. "xrecv" looks too much like my
> personal convention of adding an "x" to the begi
Thanks, I've merged this.
Ethan
On Thu, Sep 8, 2011 at 13:27, Ben Pfaff wrote:
> On Tue, Sep 06, 2011 at 07:32:27PM -0700, Ethan Jackson wrote:
>> Before this patch, ofproto-dpif would not forward any LACP or CFM
>> packets regardless of whether or not the relevant modules were
>> configured on
Thanks, I've merged this patch and the whitespace cleanup patch before it.
Ethan
On Thu, Sep 8, 2011 at 13:24, Ben Pfaff wrote:
> On Tue, Sep 06, 2011 at 07:32:26PM -0700, Ethan Jackson wrote:
>> There's no particular reason to force users of the LACP module to
>> be aware of the lacp_pdu struct
I've decided to drop this patch as it's no longer necessary. I'll be
sending out a revised version of the series shortly.
Ethan
On Thu, Sep 8, 2011 at 13:24, Ben Pfaff wrote:
> Looks good, thanks.
>
___
dev mailing list
dev@openvswitch.org
http://open
Currently OVS uses its own hashing implmentation for hash tables
which has some problems, e.g. error case on deletion code.
Following patch replaces that with hlist based hash table which is
consistent with other kernel hash tables. As Jesse suggested, flex-array
is used for allocating hash bucket
On Fri, Sep 09, 2011 at 08:49:19AM +0900, Simon Horman wrote:
> On Thu, Sep 08, 2011 at 01:11:07PM -0700, Ben Pfaff wrote:
> > On Wed, Sep 07, 2011 at 10:10:31AM +0900, Simon Horman wrote:
> > > When starting openvswtich-vswitch fail gracefully if
> > > modules can't be loaded. Otherwise package in
Please see inline.
Thanks,
-Hao
On Thu, Sep 8, 2011 at 4:27 PM, Ben Pfaff wrote:
> The comments didn't say how this should work, so this clarifies it.
> ---
> ofproto/ofproto-provider.h | 11 ---
> ofproto/ofproto.c | 24 ++--
> 2 files changed, 30 ins
On Thu, Sep 08, 2011 at 01:11:07PM -0700, Ben Pfaff wrote:
> On Wed, Sep 07, 2011 at 10:10:31AM +0900, Simon Horman wrote:
> > When starting openvswtich-vswitch fail gracefully if
> > modules can't be loaded. Otherwise package install will
> > fail if the openvswitch_mod modules is not available.
>
On Thu, Sep 08, 2011 at 04:38:54PM -0700, Jesse Gross wrote:
> On Thu, Sep 8, 2011 at 4:37 PM, Ben Pfaff wrote:
> > On Thu, Sep 08, 2011 at 03:26:04PM -0700, Jesse Gross wrote:
> >> On Thu, Sep 8, 2011 at 11:36 AM, Ben Pfaff wrote:
> >> > When ovs-vswitchd executes actions on a synthesized packet
On Thu, Sep 8, 2011 at 4:37 PM, Ben Pfaff wrote:
> On Thu, Sep 08, 2011 at 03:26:04PM -0700, Jesse Gross wrote:
>> On Thu, Sep 8, 2011 at 11:36 AM, Ben Pfaff wrote:
>> > When ovs-vswitchd executes actions on a synthesized packet, that is, on a
>> > packet that is not being forwarded from any part
On Thu, Sep 08, 2011 at 03:26:04PM -0700, Jesse Gross wrote:
> On Thu, Sep 8, 2011 at 11:36 AM, Ben Pfaff wrote:
> > When ovs-vswitchd executes actions on a synthesized packet, that is, on a
> > packet that is not being forwarded from any particular port but is being
> > generated by ovs-vswitchd
On Tue, Sep 6, 2011 at 8:37 PM, Pravin Shelar wrote:
> Currently OVS uses its own hashing implmentation for hash tables
> which has some problems, e.g. error case on deletion code.
> Following patch replaces that with hlist based hash table which is
> consistent with other kernel hash tables.
This documented what I intended to implement and what I thought I had
implemented, but not what the code actually did. It is a little easier to
fix the documentation to match the implementation than vice versa, so this
commit does so.
Reported-by: Hao Zheng
---
ofproto/ofproto-provider.h |4
Hao pointed out that the documentation of the async interface was
wrong in one spot, and I noticed that it was missing some details
elsewhere too.
Ben Pfaff (2):
ofproto: Fix documentation for calls to ->rule_destruct().
ofproto: Document that ->rule_construct() should uninitialize victim
The comments didn't say how this should work, so this clarifies it.
---
ofproto/ofproto-provider.h | 11 ---
ofproto/ofproto.c | 24 ++--
2 files changed, 30 insertions(+), 5 deletions(-)
diff --git a/ofproto/ofproto-provider.h b/ofproto/ofproto-provider.h
On Thu, Sep 8, 2011 at 3:50 PM, Ben Pfaff wrote:
> On Thu, Sep 08, 2011 at 03:38:25PM -0700, Jesse Gross wrote:
>> When we execute a packet from userspace we first extract the header
>> fields from the packet and then add supplied metadata. However, we
>> compute the hash of the packet in between
On Wed, Sep 7, 2011 at 5:50 PM, Pravin Shelar wrote:
> Currently the kernel vlan actions mirror those used by OpenFlow 1.0.
> i.e. MODIFY and STRIP. More flexible approach is to have an action to push a
> tag and pop a tag off, so that it can handle multiple levels of vlan
> tags. Plus it aligns w
On Thu, Sep 08, 2011 at 03:38:25PM -0700, Jesse Gross wrote:
> When we execute a packet from userspace we first extract the header
> fields from the packet and then add supplied metadata. However, we
> compute the hash of the packet in between these two steps despite
> the fact that the metadata c
When we execute a packet from userspace we first extract the header
fields from the packet and then add supplied metadata. However, we
compute the hash of the packet in between these two steps despite
the fact that the metadata can affect the hash. This can lead to
two separate hashes for packets
On Thu, Sep 8, 2011 at 11:36 AM, Ben Pfaff wrote:
> When ovs-vswitchd executes actions on a synthesized packet, that is, on a
> packet that is not being forwarded from any particular port but is being
> generated by ovs-vswitchd itself or by an OpenFlow controller (using a
> OFPT_PACKET_OUT messag
On Wed, Sep 7, 2011 at 4:41 PM, Pravin Shelar wrote:
> Remove iflink from vport interface. iflink is not used anywhere in
> OVS. So there is not need to have iflink as vport attribute.
>
> Signed-off-by: Pravin B Shelar
Thanks, looks good. The one thing that I was slightly concerned about
i
On Thu, Sep 08, 2011 at 11:28:27AM -0700, Ethan Jackson wrote:
> Seems fine to me. Out of curiosity: Is this compatible with the 1.0
> spec? I wonder if anyone is relying on the old behavior? Seems
> unlikely I suppose.
As far as I can tell, OpenFlow 1.0 doesn't specify this. It does say:
On Wed, Sep 07, 2011 at 07:35:02PM -0700, Ethan Jackson wrote:
> I think the -packet option needs to be surrounded by square braces in
> the man page.
>
> I may be misreading the man page, but I don't think it actually
> explains what the -packet option does. Should we document it at all?
> Perha
On Tue, Sep 6, 2011 at 7:02 PM, Pravin Shelar wrote:
> Following patch fixes rcu-dereferences-check warning msg by annotating rcu
> dereferences for BH context.
>
> --8<--
> ===
> [ INFO: suspicious
That's a better name, thanks. Or even "cfm_disabled".
On Thu, Sep 08, 2011 at 01:33:10PM -0700, Ethan Jackson wrote:
> True, perhaps I will call it call it cleanup.
>
> Thanks,
>
> Ethan
>
> On Thu, Sep 8, 2011 at 13:31, Ben Pfaff wrote:
> > The label "error" is odd. ?It's not any normal kind
[re-adding dev@openvswitch.org]
On Thu, Sep 08, 2011 at 02:13:51PM -0700, Ethan Jackson wrote:
> > Why 6 bytes? ?Why not, for example, 8?
>
> Justin and Sanjay thought 6 was a fairly standard number. I
> personally would prefer two so we can drop this patch altogether.
:-)
> > I guess there mu
On Tue, Sep 06, 2011 at 07:32:34PM -0700, Ethan Jackson wrote:
> A controller may want to know which MPIDs are reachable from an
> interface configured with CFM. This patch regularly writes this
> information to the database.
>
> Bug #7014.
In cfm_get_remote_mpids(), the string being formatted h
[adding d...@openvswich.org back, did you drop it accidentally?]
On Thu, Sep 08, 2011 at 02:00:39PM -0700, Ethan Jackson wrote:
> > Is it sufficient to use a different destination MAC or should we use a
> > different Ethertype (in practice LLC+SNAP) also?
>
> I personally think it's sufficient.
On Tue, Sep 06, 2011 at 07:32:33PM -0700, Ethan Jackson wrote:
> 802.1ag only allows for MPIDs in the range [1, 8191]. This is
> restrictive enough to make assignment of MPIDs to instances of OVS
> awkward. This patch allows six byte MPIDs when running in extended
> mode.
>
> Bug #7014.
Why 6 b
On Tue, Sep 06, 2011 at 07:32:32PM -0700, Ethan Jackson wrote:
> The standard CFM protocol only allows a handful of transmission
> rates. This is particularly problematic if you want to support a
> transmission rate slower than 100 ms and faster than 1000 ms.
>
> This patch allows arbitrary trans
Here's my real review of patch 8.
On Tue, Sep 06, 2011 at 07:32:31PM -0700, Ethan Jackson wrote:
> @@ -38,6 +38,9 @@ VLOG_DEFINE_THIS_MODULE(cfm);
>
> /* Ethernet destination address of CCM packets. */
> static const uint8_t eth_addr_ccm[6] = { 0x01, 0x80, 0xC2, 0x00, 0x00, 0x30
> };
> +stati
On Thu, Sep 08, 2011 at 01:47:29PM -0700, Ben Pfaff wrote:
> On Tue, Sep 06, 2011 at 07:32:31PM -0700, Ethan Jackson wrote:
> > The new extended mode introduced in this patch will be used for
> > features which break wire compatibility with 802.1ag compliant
> > implementations.
> >
> > Bug #7014.
On Tue, Sep 06, 2011 at 07:32:31PM -0700, Ethan Jackson wrote:
> The new extended mode introduced in this patch will be used for
> features which break wire compatibility with 802.1ag compliant
> implementations.
>
> Bug #7014.
Seems OK to me.
The documentation could probably use some additional
Userspace changes seem fine.
Ethan
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On Thu, Sep 08, 2011 at 01:37:01PM -0700, Ben Pfaff wrote:
> Is "xrecv" standard terminology for LACP?
For CFM, I mean, of course.
> Otherwise I'd prefer
> something a bit more spelled out. "xrecv" looks too much like my
> personal convention of adding an "x" to the beginning of a struct
> m
Is "xrecv" standard terminology for LACP? Otherwise I'd prefer
something a bit more spelled out. "xrecv" looks too much like my
personal convention of adding an "x" to the beginning of a struct
member name to find all the references to it via compiler errors. It
makes me think that somehow I com
True, perhaps I will call it call it cleanup.
Thanks,
Ethan
On Thu, Sep 8, 2011 at 13:31, Ben Pfaff wrote:
> The label "error" is odd. It's not any normal kind of "error" for CFM
> not to be enabled on a port. But the change looks otherwise good to
> me.
>
The label "error" is odd. It's not any normal kind of "error" for CFM
not to be enabled on a port. But the change looks otherwise good to
me.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On Tue, Sep 06, 2011 at 07:32:27PM -0700, Ethan Jackson wrote:
> Before this patch, ofproto-dpif would not forward any LACP or CFM
> packets regardless of whether or not the relevant modules were
> configured on the in_port.
>
> Feature #6316.
Looks good, thank you.
__
On Tue, Sep 06, 2011 at 07:32:26PM -0700, Ethan Jackson wrote:
> There's no particular reason to force users of the LACP module to
> be aware of the lacp_pdu structure. This patch hides that
> information in the LACP module implementation. This results in
> slightly cleaner code which is more con
Looks good, thanks.
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On Wed, Sep 07, 2011 at 10:10:32AM +0900, Simon Horman wrote:
> diff --git a/debian/changelog b/debian/changelog
> index 3940891..1f510f8 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,14 @@
> +openvswitch (1.2.1-3) unstable; urgency=low
> +
> + * Allow the openvswitch-switc
On Wed, Sep 07, 2011 at 10:10:31AM +0900, Simon Horman wrote:
> When starting openvswtich-vswitch fail gracefully if
> modules can't be loaded. Otherwise package install will
> fail if the openvswitch_mod modules is not available.
>
> This resolves a regression between 1.1.1 and 1.2.1.
>
> This m
On Wed, Sep 07, 2011 at 10:10:30AM +0900, Simon Horman wrote:
> On Debian there is a need for the init scripts to die gracefully
> if module insertion fails. In such a case it is desirable to print
> some sort of informative message.
>
> By adding the load-kmod sub-command to ovs-ctl init scripts
Le 08/09/2011 21:43, Ben Pfaff a écrit :
> On Fri, Aug 26, 2011 at 01:19:40PM -0700, Ben Pfaff wrote:
>> From: Philippe Jung
>>
>> Significant updates by Ben Pfaff, including:
>>
>> * Comment, coding style, indentation updates.
>> * Documentation improved.
>> * Added tests.
>> * Dropped PORT_VLAN_
After testing that the instructions in INSTALL.RHEL still worked for
me, I pushed patch #1 and the revised patch #2 to "master". Thank
you!
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
On Fri, Aug 26, 2011 at 01:19:40PM -0700, Ben Pfaff wrote:
> From: Philippe Jung
>
> Significant updates by Ben Pfaff, including:
>
> * Comment, coding style, indentation updates.
> * Documentation improved.
> * Added tests.
> * Dropped PORT_VLAN_EMPTY.
Philippe, would you mind taking a look at
Thanks, I pushed this.
On Wed, Sep 07, 2011 at 01:43:25PM -0700, Ethan Jackson wrote:
> Looks good.
>
> Ethan
>
> On Tue, Sep 6, 2011 at 09:34, Ben Pfaff wrote:
> > One of the current goals of netlink-protocol.h, for better or for worse, is
> > to ensure that the same definitions are available
---
lib/ofp-util.c | 536 +--
tests/ofp-print.at |2 +-
2 files changed, 222 insertions(+), 316 deletions(-)
diff --git a/lib/ofp-util.c b/lib/ofp-util.c
index 0a020d3..1e95d04 100644
--- a/lib/ofp-util.c
+++ b/lib/ofp-util.c
@@ -282,111 +2
---
lib/ofp-util.c | 70 ---
lib/ofp-util.h |2 +
2 files changed, 43 insertions(+), 29 deletions(-)
diff --git a/lib/ofp-util.c b/lib/ofp-util.c
index 1e95d04..156d974 100644
--- a/lib/ofp-util.c
+++ b/lib/ofp-util.c
@@ -343,14 +343,13 @@
---
include/openflow/nicira-ext.h |9 -
ofproto/ofproto.c | 38 +++---
2 files changed, 39 insertions(+), 8 deletions(-)
diff --git a/include/openflow/nicira-ext.h b/include/openflow/nicira-ext.h
index 4fab6f1..fe725be 100644
--- a/include
---
include/openflow/nicira-ext.h |3 +++
ofproto/ofproto.c |3 +--
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/openflow/nicira-ext.h b/include/openflow/nicira-ext.h
index fe725be..890e974 100644
--- a/include/openflow/nicira-ext.h
+++ b/include/openf
These commits improve logging of OpenFlow errors on the switch side
and report more specific OpenFlow error codes to the controller in
some situations.
Ben Pfaff (6):
ofp-util: Avoid linear search in OpenFlow message type decoding.
ofp-util: New function ofputil_decode_msg_type_partial().
of
Some invalid ports (those above the maximum port number supported by the
datapath, including OpenFlow reserved ports that are not translated by OVS
into some other number) will be rejected by the datapath. It's better to
catch these early and send back an appropriate OpenFlow error code, rather
th
Until now, logging of OpenFlow error replies sent to controllers has been
haphazard. This commit logs them centrally, ensuring that every OpenFlow
error sent to a controller is logged.
At the same time, we can eliminate the individual log messages that a few
OpenFlow errors triggered.
---
ofprot
Seems like a very small cleanup.
---
ofproto/ofproto.c |3 +--
ofproto/pktbuf.c | 10 --
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/ofproto/ofproto.c b/ofproto/ofproto.c
index 849a376..090d4d3 100644
--- a/ofproto/ofproto.c
+++ b/ofproto/ofproto.c
@@ -1581,7 +158
Commit d1e9b9bf3 "nicira-ext: Renumber NXT_FLOW_MOD_TABLE_ID" eliminated
the need for the NXT_SET_FLOW_FORMAT and NXT_FLOW_MOD_TABLE_ID commands to
have different sizes, so asserting that they are different isn't useful
anymore (although it is still correct and always will be).
---
lib/ofp-util.c
---
lib/odp-util.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/lib/odp-util.c b/lib/odp-util.c
index b42a03c..5b86b47 100644
--- a/lib/odp-util.c
+++ b/lib/odp-util.c
@@ -989,10 +989,6 @@ odp_flow_key_to_flow(const struct nlattr *key, size_t
key_len,
b
When ovs-vswitchd executes actions on a synthesized packet, that is, on a
packet that is not being forwarded from any particular port but is being
generated by ovs-vswitchd itself or by an OpenFlow controller (using a
OFPT_PACKET_OUT message with an in_port of OFPP_NONE), there is no good
choice fo
Seems fine to me. Out of curiosity: Is this compatible with the 1.0
spec? I wonder if anyone is relying on the old behavior? Seems
unlikely I suppose.
Ethan
On Fri, Aug 19, 2011 at 15:28, Ben Pfaff wrote:
> I finally found a good use for hard timeouts in OpenFlow, but they require
> a slight
Looks good,
Ethan
On Fri, Aug 19, 2011 at 15:28, Ben Pfaff wrote:
> This allows a command like "test-openflowd --enable-dummy dummy@br0
> --ports=dummy@eth0,dummy@eth1,dummy@eth2" to create a dummy datapath with
> a number of dummy ports. This is more useful for testing than a dummy
> datapath
The tables have different purposes. A flow in the classifier is an
OpenFlow flow that may contain wildcards. A flow in the datapath
(e.g. dp_netdev) is always exact-match (to allow hashing).
On Thu, Sep 08, 2011 at 07:13:24PM +0500, Bibrak Qamar wrote:
> But when dpif-netdev is used does it stor
But when dpif-netdev is used does it store flows in both of the tables? I
mean why are we maintaining two tables?
struct classifier {
int n_rules;/* Total number of rules. */
struct hmap tables; */* Contains "struct cls_table"s. */*
};
struct dp_netdev {
..
..
On Thu, Sep 08, 2011 at 06:10:45PM +0500, Bibrak Qamar wrote:
> Ok now I have got some idea. In the classifier there is a data structure
> which stores the rules, i.e
>
> struct classifier {
> int n_rules;/* Total number of rules. */
> struct hmap tables; /* Contain
Ok now I have got some idea. In the classifier there is a data structure
which stores the rules, i.e
struct classifier {
int n_rules;/* Total number of rules. */
struct hmap tables; /* Contains "struct cls_table"s. */
};
And in the netdev there is also a data stru
Eliminar suscripción
Haga clic en
http://mybonusweb.ip-zone.com/ccm/unsubscribe/confirm/email/dev%40openvswitch.org/code/SZJLodCO
para completar la baja.
Si no ha solicitado ese mensaje, simplemente lo ignora y su suscripción no se
eliminará.
Si usted tiene al
From: Valient Gough
Add tunnel key support to CAPWAP vport. Uses the optional WSI field in a
CAPWAP header to store a 64bit key. It can also be used without keys, in which
case it is backward compatible with the old code. Documentation about the
WSI field format is in CAPWAP.txt.
Signed-off-b
On Tue, Aug 23, 2011 at 11:11 PM, Simon Horman wrote:
> On Tue, Aug 02, 2011 at 01:56:22PM +0700, Jesse Gross wrote:
>> On Tue, Aug 2, 2011 at 12:01 PM, Simon Horman wrote:
>> > Hi,
>> >
>> > in an effort to move things forward I decided to take the liberty
>> > of posting a fresh version of this
There are multiple layers where you can see packets come in, but
handle_upcall() in "ofproto/ofproto-dpif.c" is probably a good place to start
(and the "DPIF_UC_MISS" case in particular). You can then go up or down the
call stack depending on what you want to see.
--Justin
On Sep 7, 2011, at
86 matches
Mail list logo
