On Mon, Aug 22, 2016 at 12:20:17PM +0200, Martin Pieuchot wrote:
> @@ -1495,17 +1512,17 @@ nd6_resolve(struct ifnet *ifp, struct rt
> - error = rt_checkgate(rt0, );
> - if (error) {
> + rt = rt_getll(rt0);
> +
> + if (ISSET(rt->rt_flags, RTF_REJECT)) {
> m_freem(m);
>
On 19/08/16(Fri) 19:19, Alexander Bluhm wrote:
> On Mon, Aug 15, 2016 at 01:52:46PM +0200, Martin Pieuchot wrote:
> > More tests, comments, ok are welcome.
>
> There is an issue with path mtu discovery that my regression test
> found, but i think that can be fixed with this diff in tree.
I
On Mon, Aug 15, 2016 at 01:52:46PM +0200, Martin Pieuchot wrote:
> More tests, comments, ok are welcome.
There is an issue with path mtu discovery that my regression test
found, but i think that can be fixed with this diff in tree.
> +/*
> + * Invalidate the cached route entry of the gateway
On 15/08/16(Mon) 13:52, Martin Pieuchot wrote:
> On 11/08/16(Thu) 16:04, Martin Pieuchot wrote:
> > One of the remaining SMP issue with our routing table usage is to
> > guarantee that the L2 entry referenced by a RTF_GATEWAY route via
> > the ``rt_gwroute'' pointer wont be replaced/invalidated by
On 11/08/16(Thu) 16:04, Martin Pieuchot wrote:
> One of the remaining SMP issue with our routing table usage is to
> guarantee that the L2 entry referenced by a RTF_GATEWAY route via
> the ``rt_gwroute'' pointer wont be replaced/invalidated by another
> CPU while we are filling the address field
One of the remaining SMP issue with our routing table usage is to
guarantee that the L2 entry referenced by a RTF_GATEWAY route via
the ``rt_gwroute'' pointer wont be replaced/invalidated by another
CPU while we are filling the address field of an Ethernet frame.
The most efficient way,
