Great, thanks for the reviews, I'll merge the series shortly.
Ethan
On Thu, Jan 3, 2013 at 5:11 PM, Jesse Gross wrote:
> On Thu, Jan 3, 2013 at 4:35 PM, Ethan Jackson wrote:
> > Oops thanks for pointing that out. This version moves the unassociated
> port
> > log message back to handle_miss_u
On Thu, Jan 3, 2013 at 4:35 PM, Ethan Jackson wrote:
> Oops thanks for pointing that out. This version moves the unassociated port
> log message back to handle_miss_upcall(). This turned out to be a bit awkward
> to implement, so I had to refactor the patch slightly. The main difference is
> th
Oops thanks for pointing that out. This version moves the unassociated port
log message back to handle_miss_upcall(). This turned out to be a bit awkward
to implement, so I had to refactor the patch slightly. The main difference is
that now ofproto_receive() returns an errno (as Ben suggested ea
On Wed, Jan 2, 2013 at 5:00 PM, Ethan Jackson wrote:
> Sounds good. I've applied the following minor changes to the patch which I
> think is good enough for now. Let me know if there's anthing else that needs
> to change before we do the appropriate refactoring.
There's one other thing that I h
Sounds good. I've applied the following minor changes to the patch which I
think is good enough for now. Let me know if there's anthing else that needs
to change before we do the appropriate refactoring.
Ethan
---
ofproto/ofproto-dpif.c |6 +-
1 file changed, 5 insertions(+), 1 deletio
I'm fine with that too.
On Thu, Dec 27, 2012 at 6:09 PM, Ben Pfaff wrote:
> Personally I'm happy enough with that.
>
> On Thu, Dec 27, 2012 at 03:07:37PM -0800, Ethan Jackson wrote:
>> All of this makes sense. However I think it's out of the scope of the
>> original intention of this patch which
Personally I'm happy enough with that.
On Thu, Dec 27, 2012 at 03:07:37PM -0800, Ethan Jackson wrote:
> All of this makes sense. However I think it's out of the scope of the
> original intention of this patch which was simply to refactor some common
> code. The patch as is, maintains the current
All of this makes sense. However I think it's out of the scope of the
original intention of this patch which was simply to refactor some common
code. The patch as is, maintains the current (admittedly broken) behavior
of trace. I propose we merge it without changing the semantics of trace
for now
On Thu, Dec 27, 2012 at 3:54 PM, Ben Pfaff wrote:
> On Thu, Dec 27, 2012 at 03:35:27PM -0500, Jesse Gross wrote:
>> On Thu, Dec 27, 2012 at 3:30 PM, Ben Pfaff wrote:
>> > On Thu, Dec 27, 2012 at 11:37:31AM -0800, Ethan Jackson wrote:
>> >> > Why shouldn't we give up in trace, as we do in the pack
On Thu, Dec 27, 2012 at 03:35:27PM -0500, Jesse Gross wrote:
> On Thu, Dec 27, 2012 at 3:30 PM, Ben Pfaff wrote:
> > On Thu, Dec 27, 2012 at 11:37:31AM -0800, Ethan Jackson wrote:
> >> > Why shouldn't we give up in trace, as we do in the packet receive
> >> > path, if the port can't be found? "tr
On Thu, Dec 27, 2012 at 3:30 PM, Ben Pfaff wrote:
> On Thu, Dec 27, 2012 at 11:37:31AM -0800, Ethan Jackson wrote:
>> > Why shouldn't we give up in trace, as we do in the packet receive
>> > path, if the port can't be found? "trace" is supposed to match the
>> > packet receive path (otherwise it
On Thu, Dec 27, 2012 at 03:29:18PM -0500, Jesse Gross wrote:
> On Thu, Dec 27, 2012 at 2:37 PM, Ethan Jackson wrote:
> >
> >> Why shouldn't we give up in trace, as we do in the packet receive
> >> path, if the port can't be found? "trace" is supposed to match the
> >> packet receive path (otherwi
On Thu, Dec 27, 2012 at 11:37:31AM -0800, Ethan Jackson wrote:
> > Why shouldn't we give up in trace, as we do in the packet receive
> > path, if the port can't be found? "trace" is supposed to match the
> > packet receive path (otherwise it isn't as useful). I guess the
> > reason is that we don
On Thu, Dec 27, 2012 at 2:37 PM, Ethan Jackson wrote:
>
>> Why shouldn't we give up in trace, as we do in the packet receive
>> path, if the port can't be found? "trace" is supposed to match the
>> packet receive path (otherwise it isn't as useful). I guess the
>> reason is that we don't have to
> Why shouldn't we give up in trace, as we do in the packet receive
> path, if the port can't be found? "trace" is supposed to match the
> packet receive path (otherwise it isn't as useful). I guess the
> reason is that we don't have to, since the user specified the ofproto
> name, but I think th
On Wed, Dec 26, 2012 at 05:16:41PM -0800, Ethan Jackson wrote:
> Before translating a datapath flow key into actions, ofproto-dpif
> must parse it, tweak it, and figure out what ofproto_dpif it
> belongs to. This patch brings all this logic into one place where
> it will be easier to extend in the
On Wed, Dec 26, 2012 at 8:16 PM, Ethan Jackson wrote:
> +ofproto_receive(const struct dpif_backer *backer, struct ofpbuf *packet,
> +const struct nlattr *key, size_t key_len,
> +struct flow *flow, struct ofproto_dpif **ofproto,
> +uint32_t *odp_in_po
17 matches
Mail list logo
