On Fri, May 04, 2007 at 02:33:45PM +0100, David Howells ([EMAIL PROTECTED])
wrote:
> Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> > That is the same, dst is dereferenced as rtable.
> > Cloned dst is returned, so it must be put back at the ned of the usage.
>
> If that's the case, then why do
On Fri, May 04, 2007 at 03:59:18PM +0200, Patrick McHardy ([EMAIL PROTECTED])
wrote:
> >>You need dst_release(&rt->u.dst) here.
> >
> >
> > Thanks. I think Evgeniy's code may be wrong then. He ends with a
> > dst_clone(), which I think is superfluous.
>
>
> Yes, that looks wrong.
Main idea
David Howells wrote:
> Patrick McHardy <[EMAIL PROTECTED]> wrote:
>
>
>>htons()
>
>
> Blech. Thanks. Does it actually matter what ports are specified?
It matters when IPsec port selectors are used to find the correct
policy.
>>You need dst_release(&rt->u.dst) here.
>
>
> Thanks. I think
Patrick McHardy <[EMAIL PROTECTED]> wrote:
> htons()
Blech. Thanks. Does it actually matter what ports are specified?
> You need dst_release(&rt->u.dst) here.
Thanks. I think Evgeniy's code may be wrong then. He ends with a
dst_clone(), which I think is superfluous.
David
-
To unsubscribe
David Howells wrote:
> static void rxrpc_assess_MTU_size(struct rxrpc_peer *peer)
> {
> struct rtable *rt;
> struct flowi fl;
> int ret;
>
> peer->if_mtu = 1500;
>
> memset(&fl, 0, sizeof(fl));
>
> switch (peer->srx.transport.family) {
> case AF_INET:
>
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> That is the same, dst is dereferenced as rtable.
> Cloned dst is returned, so it must be put back at the ned of the usage.
If that's the case, then why do you bother to clone it in route_get_raw()?
Surely that'll give you *two* clones...
BTW, it seem
On Fri, May 04, 2007 at 02:24:49PM +0100, David Howells ([EMAIL PROTECTED])
wrote:
> Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> > > Should route_get_raw() release the rtable if gets back?
> >
> > Yes, dst entry should be released when not used anymore.
>
> I meant the rtable returned by __
On Fri, May 04, 2007 at 02:23:24PM +0100, David Howells ([EMAIL PROTECTED])
wrote:
> Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> > static int netchannel_ip_route_output_flow(struct rtable **rp, struct flowi
> > *flp, int flags)
>
> What's proto? Should that be IPPROTO_UDP?
Yep.
> David
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> > Should route_get_raw() release the rtable if gets back?
>
> Yes, dst entry should be released when not used anymore.
I meant the rtable returned by __ip_route_output_key(), not the dst.
David
-
To unsubscribe from this list: send the line "unsubsc
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> static int netchannel_ip_route_output_flow(struct rtable **rp, struct flowi
> *flp, int flags)
What's proto? Should that be IPPROTO_UDP?
David
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PR
On Fri, May 04, 2007 at 02:08:15PM +0100, David Howells ([EMAIL PROTECTED])
wrote:
>
> Should route_get_raw() release the rtable if gets back?
You can also cache returned entry and then just clone it and check
->obsolete() callback.
Something like this:
struct dst_entry *route_get(struct dst_en
On Fri, May 04, 2007 at 02:08:15PM +0100, David Howells ([EMAIL PROTECTED])
wrote:
>
> Should route_get_raw() release the rtable if gets back?
Yes, dst entry should be released when not used anymore.
> David
--
Evgeniy Polyakov
-
To unsubscribe from this list: send the line "unsubscri
Should route_get_raw() release the rtable if gets back?
David
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
David Howells <[EMAIL PROTECTED]> wrote:
> > err = __ip_route_output_key(rp, flp);
>
> Is there any way to get at this without having to link against the ipv4
> module?
Ah, nevermind. ipv4 can't be a module.
David
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the b
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> err = __ip_route_output_key(rp, flp);
Is there any way to get at this without having to link against the ipv4
module?
David
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More m
David Howells wrote:
> I would like to determine through which interface packets sent to a particular
> UDP destination will go through, and so determine the MTU size for that
> interface. Can anyone suggest a good way of doing this from within the
> kernel?
Do a route lookup (ip_route_output_ke
On Fri, May 04, 2007 at 01:48:48PM +0100, David Howells ([EMAIL PROTECTED])
wrote:
>
> Hi,
Hi David.
> I would like to determine through which interface packets sent to a particular
> UDP destination will go through, and so determine the MTU size for that
> interface. Can anyone suggest a good
Hi,
I would like to determine through which interface packets sent to a particular
UDP destination will go through, and so determine the MTU size for that
interface. Can anyone suggest a good way of doing this from within the
kernel?
Doing this will permit AF_RXRPC to obtain a better initial gu
18 matches
Mail list logo
