List available: US businesses
- 4 million emails
Price until Friday: $99
CLICK HERE TO ORDER
File
Available for download in excel format
Some of the business
categories
Previously, the function returned an "ofproto_dpif", but it makes more
sense to return an "ofbundle". This will also be helpful in a
forthcoming commit.
Signed-off-by: Justin Pettit
---
ofproto/ofproto-dpif.c | 30 --
1 files changed, 12 insertions(+), 18 deletions
Both mirroring and "normal" processing make use of the input bundle to
perform various sanity checks. Controller-generated traffic typically
uses an ingress port of OFPP_NONE, which doesn't have a corresponding
input bundle. This commit fakes one up well enough that mirroring and
"normal" process
Fixed according to comments from Jesse.
v2-v3:
Moved genl compat code to datapath dir.
Removed locking from init and exit code paths.
v1-v2:
Fixed -ENOMEM case from genl_exec()
--8<--cut here-->8-
genl_lock is not exported
> I think that this changes correct code into a memory leak. The
> list_remove() in the LIST_FOR_EACH_SAFE loop inside handle_flow_miss()
> ensures that the caller will not free the packet with its
> ofpbuf_list_delete() call (since the packet is no longer in the list).
Ah yes you're right. I mi
On Tue, Jan 03, 2012 at 02:09:42PM -0800, Ethan Jackson wrote:
> handle_flow_miss() transfers ownership of its packets to
> send_packet_in_miss(), but its caller deletes these packets upon
> return. Future patches will remove support for un-cloned calls
> altogether. Found by inspection.
>
> Sig
On Tue, Jan 03, 2012 at 02:24:12PM -0800, Ben Pfaff wrote:
> On Tue, Jan 03, 2012 at 04:02:44PM -0600, Ethan Jackson wrote:
> > Looking through the ofproto-dpif code, all of the callers either do or
> > *should* be cloning the packet when using a packet_in action. One
> > caller in handle_miss_upc
On Tue, Jan 03, 2012 at 04:02:44PM -0600, Ethan Jackson wrote:
> Looking through the ofproto-dpif code, all of the callers either do or
> *should* be cloning the packet when using a packet_in action. One
> caller in handle_miss_upcalls, doesn't clone, but should because it
> later reuses the packe
handle_flow_miss() transfers ownership of its packets to
send_packet_in_miss(), but its caller deletes these packets upon
return. Future patches will remove support for un-cloned calls
altogether. Found by inspection.
Signed-off-by: Ethan Jackson
---
ofproto/ofproto-dpif.c |2 +-
1 files c
On Tue, Jan 03, 2012 at 01:45:42PM -0800, Justin Pettit wrote:
> Thanks for tracking this down so quickly. Looks good to me. Does
> the problem exist in later branches?
No. On later branches, port configuration is "atomic": we don't do
part of it (leaving the port in an invalid state), then go
> Although it would be ideal to embed the new structure inside struct
> flow, I actually had in mind to define a structure that wasn't
> necessarily used inside struct flow. It seems to me that such an
> approach would better than individual members, even if it falls short
> of perfection.
That's
Everything made sense, just a few responses:
On Tue, Jan 03, 2012 at 03:46:47PM -0600, Ethan Jackson wrote:
> > It might be reasonable to reuse the NXFF_* values for the 'format'
> > member in nxt_set_packet_in_format, instead of defining new NXPIF_*
> > values. ?Or you could even define a new NXF
> ../lib/ofp-util.c: In function 'ofputil_decode_packet_in':
> ../lib/ofp-util.c:1613: error: too many arguments to function
> 'nx_pull_match'
> ../lib/ofp-util.c: In function 'ofputil_encode_packet_in':
> ../lib/ofp-util.c:1693: error: too many arguments to function
> 'nx_put_match'
Thanks for tracking this down so quickly. Looks good to me. Does the problem
exist in later branches?
Did you want to add Dominic to AUTHORS? I suspect you, like me, assumed he was
already there.
--Justin
On Jan 3, 2012, at 1:23 PM, Ben Pfaff wrote:
> If a bridge is in standalone mode and
On Tue, Jan 03, 2012 at 01:28:39PM -0800, Justin Pettit wrote:
> On Dec 27, 2011, at 1:01 PM, Ben Pfaff wrote:
>
> > @@ -3425,22 +3426,23 @@ collect_splinter_vlans(const struct
> > ovsrec_open_vswitch *ovs_cfg)
> > for (k = 0; k < port_cfg->n_interfaces; k++) {
> > str
On Dec 27, 2011, at 1:01 PM, Ben Pfaff wrote:
> @@ -3425,22 +3426,23 @@ collect_splinter_vlans(const struct
> ovsrec_open_vswitch *ovs_cfg)
> for (k = 0; k < port_cfg->n_interfaces; k++) {
> struct ovsrec_interface *iface_cfg = port_cfg->interfaces[k];
>
> +
If a bridge is in standalone mode and no controllers are configured, and
then reconfiguration (e.g. ovs-vsctl) adds an SLB or TCP-balanced bond,
and at the moment of reconfiguration active kernel flows exist that output
to the newly added bond, then ovs-vswitchd would segfault because the
bond's 'b
On Tue, Dec 27, 2011 at 01:01:55PM -0800, Ben Pfaff wrote:
> It's natural to add an access port to a bridge and expect that trunk ports
> will then immediately start to work properly with that VLAN without
> additional configuration. This change makes that happen.
>
> Signed-off-by: Ben Pfaff
I
On Tue, Jan 03, 2012 at 10:50:16AM -0800, Ethan Jackson wrote:
> I decided to add a patch which masks out the CFI bit in eth_push_vlan().
> It will be included when I resend the series.
>
> Here is an incremental.
Incremental looks fine, thanks.
___
dev
I decided to add a patch which masks out the CFI bit in eth_push_vlan().
It will be included when I resend the series.
Here is an incremental.
---
ofproto/ofproto-dpif.c | 24 ++--
1 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/ofproto/ofproto-dpif.c b/ofp
On Tue, Jan 03, 2012 at 12:15:11PM -0600, Ethan Jackson wrote:
> > You could simplify further by making pktbuf_save() take a pointer and
> > length instead of a pktbuf.
>
> That's a good idea. I'll write up another patch and insert it before this
> one.
>
> The changes are getting complex enoug
> You could simplify further by making pktbuf_save() take a pointer and
> length instead of a pktbuf.
That's a good idea. I'll write up another patch and insert it before this one.
The changes are getting complex enough that I intend to resend the
entire series before finally merging it btw.
ET
On Tue, Jan 03, 2012 at 12:13:33PM -0600, Ethan Jackson wrote:
> > One comment: other ofputil_decode_*() functions call
> > ofputil_decode_msg_type() and check the result because they can actually
> > decode more than one message format. ?But this function only decodes a
> > single message format,
> One comment: other ofputil_decode_*() functions call
> ofputil_decode_msg_type() and check the result because they can actually
> decode more than one message format. But this function only decodes a
> single message format, so I think that it is better for it to simply
> assume that the caller
On Tue, Jan 03, 2012 at 10:05:52AM -0800, Ethan Jackson wrote:
> Here's another version of the patch which takes into account your comments.
Thanks.
You could simplify further by making pktbuf_save() take a pointer and
length instead of a pktbuf.
I see that pktbuf_save() should also start alloca
Here's another version of the patch which takes into account your comments.
---
This will make the memory ownership clearer when future patches
make more extensive use of ofputil_packet_in.
Signed-off-by: Ethan Jackson
---
lib/ofp-util.c |9 -
lib/ofp-util.h |4 +
26 matches
Mail list logo
