On Thu, Jun 27, 2013 at 04:41:18PM -0700, Ethan Jackson wrote:
> > That's OK, but it would also be OK to just mention how one can tell.
>
> That's the problem. There's no obvious way to tell other than just
> knowing that it's lacp_process_packet(). I could mark the function
> somehow, but that'
> That's OK, but it would also be OK to just mention how one can tell.
That's the problem. There's no obvious way to tell other than just
knowing that it's lacp_process_packet(). I could mark the function
somehow, but that's weird. The new patch is better. I'll send it out
soon.
Ethan
X-CudaM
On Thu, Jun 27, 2013 at 04:35:55PM -0700, Ethan Jackson wrote:
> > There are other lacp_*() functions that don't gracefully handle a null
> > slave, how can one figure out which ones matter?
>
> I originally handled them, but then realized that the only one that
> actually mattered was lacp_proces
> There are other lacp_*() functions that don't gracefully handle a null
> slave, how can one figure out which ones matter?
I originally handled them, but then realized that the only one that
actually mattered was lacp_process_packet(). That said, I think
you're right that it's important to be co
On Mon, Jun 24, 2013 at 06:59:29PM -0700, Ethan Jackson wrote:
> In future patches, ofproto-dpif-xlate may be temporarily out of
> sync with ofproto-dpif proper, and pass an unknown ofport to
> lacp_process_packet(). This patch handles that edge case
> gracefully.
>
> Signed-off-by: Ethan Jackson
In future patches, ofproto-dpif-xlate may be temporarily out of
sync with ofproto-dpif proper, and pass an unknown ofport to
lacp_process_packet(). This patch handles that edge case
gracefully.
Signed-off-by: Ethan Jackson
---
lib/lacp.c |4
1 file changed, 4 insertions(+)
diff --git
