Dan McDonald wrote:
DM-14 ip_rput() E2 You lost some comments about b_next usage,
please return them.
RESP: CLARIFY
Are you referring to the follwoing comment in ip_rput_process_notdata():
/* Copy b_next - used in M_BREAK messages */
on parent ws's ip.c (L12996)?
No, but that *is* related.
Which line in specific were you commenting to
If so it is being removed as part of M_BREAK optimization dead
code cleanup. The b_next assigment should be removed as well as
its part of the M_BREAK dead code.
Gotcha.
In onnv code this optimization seems to have disappared ( see
"Seems to have"? Before removal, you need absolute belief.
This part of the block comment:
* M_BREAK are also used to pass back in multicast packets
* that are encapsulated with a source route.
Bothers me *just* enough so that we should probably make sure we aren't
hitting this codepath. A simple test:
ping -g <Surya-router-1> -g <Surya-router-2> 224.0.0.1
Would check if you get an M_BREAK on your Surya box. Assuming that's kosher,
you're in good shape.
I got the M_BREAK cleanup ( justification and the code cleanup) checked
out by THiru, but yet we will test this as you point out above.
DM-15 23834-23882 T4 Did you manage to tickle this case during
your testing? If so, great. If not, we
should discuss how to tickle this case.
RESP: No. Please provide clues on how to tickle this part to test it.
Hmmm.
* Have a test Surya node that forwards. One of its interfaces should be an
SCA 4000 (vce) that is known to properly work with HW-accelerated packets.
* Send a packet *through* the Surya node to an on-vce-link neighbor. You
should probably use dtrace's chill() action during the gap between
incomplete IRE creation and IRE completion for maximum potency.
* During the gap, have the Surya node send an IPsec-protected packet to the
SAME on-vce-link neighbor. You will have to *originate* this packet,
because if the neighbor does, you may get your IRE completed for you by
mistake.
It's tricky, but that's the high-level overview. I marked this as a '4' (and
maybe I should've marked it as a 5) because I don't think a dropped packet
during this gap is a showstopper. We drop packets for other reasons in these
cases, and MOST consumers of the SCA 4000 will NOT be forwarding over that
interface. (E.g. If punchin used an SCA 4000, it would be the Internet-side
interface, and we never forward on to Internet destinations - we use the
tunnels instead.)
I just wanted this noted for the record. Perhaps my steps above should be
noted, as that creation-to-completion gap is where a outbound HW-accelerated
packet will get dropped.
One thing you may wish to do is instead of "goto drop_pkt" is maybe create a
special ipdrop case for it. After you integrate all of these other review
changes, we can discuss how. (I will be in MPK in two weeks, BTW.)
Thanks,
Dan
_______________________________________________
networking-discuss mailing list
[email protected]
