From: Andreas Langer <an.langer@gmx.de>
To: b.a.t.m.a.n@lists.open-mesh.org
Subject: Re: [B.A.T.M.A.N.] [PATCH] batman-adv: layer2 unicast packet fragmentation enhancements
Date: Sun, 12 Sep 2010 03:14:48 +0200 [thread overview]
Message-ID: <20100912031448.6f7b11f7@rechenknecht> (raw)
In-Reply-To: <201009111126.38504.sven.eckelmann@gmx.de>
Am Sat, 11 Sep 2010 11:26:37 +0200
schrieb Sven Eckelmann <sven.eckelmann@gmx.de>:
> Andreas Langer wrote:
> > things that changed since the last patch:
> > - add support to fragment packets on every node,
> > if outgoing iface mtu is smaller as the packet
> > - add support to defragment packets on every node,
> > if outgoing iface mtu is >= original size
> > - rename some functions
>
> Is it possible to split the patch in those parts? It would make it easier to
> read it and understand the patches later.
I think it makes no sense, it belongs together. But I can put the renaming in an
extra patch. Would that be ok ?
>
> I haven't checked the patch in detail, but scrolled over it a little bit.
>
> Andreas Langer wrote:
> > This patch improves the fragmentation by also fragmenting
> > packets that came in via an interface which does not need
> > fragmentation. In addition it reassembles fragmented packets
> > as soon as the interface MTU allows it.
> >
> > Signed-off-by: Andreas Langer <an.langer at gmx.de>
> > ---
> > batman-adv/routing.c | 64 +++++++++---------------
> > batman-adv/unicast.c | 130
> > +++++++++++++++++++++++++++++++++----------------- batman-adv/unicast.h |
> > 13 ++----
> > 3 files changed, 114 insertions(+), 93 deletions(-)
> >
> > diff --git a/batman-adv/routing.c b/batman-adv/routing.c
> > index a2c64a4..e975452 100644
> > --- a/batman-adv/routing.c
> > +++ b/batman-adv/routing.c
> > @@ -1142,15 +1142,11 @@ static int route_unicast_packet(struct sk_buff
> > *skb, unsigned long flags;
> > struct unicast_packet *unicast_packet;
> > struct ethhdr *ethhdr = (struct ethhdr *)skb_mac_header(skb);
> > + int hdr_lenght = sizeof(struct unicast_packet),
> > + uni_diff = sizeof(struct unicast_frag_packet) - hdr_lenght;
> >
>
> Could you change lenght to length?
yes i can.
>
> > unicast_packet = (struct unicast_packet *)skb->data;
> >
> > - /* packet for me */
> > - if (is_my_mac(unicast_packet->dest)) {
> > - interface_rx(recv_if->soft_iface, skb, hdr_size);
> > - return NET_RX_SUCCESS;
> > - }
> > -
>
> There are different parts of the patch which makes ma a little bit curious -
> for example: why it is possible to drop that check entirely? Could that be an
> extra patch with an explanation why that can be dropped? Is it only valid in
> context of the new fragmentation handling? .
No it's not in context, recv_unicast_packet and recv_ucast_frag_packet check this,
so it makes no sense to call it again in route_unicast_packet. I'm not sure if it
came from the first fragmentation patch, i put it extra.
what are the other parts which makes you curious ?
>
> [...]
> > -static int unicast_send_frag_skb(struct sk_buff *skb, struct bat_priv
> > *bat_priv, - struct batman_if *batman_if, uint8_t dstaddr[],
> > - struct orig_node *orig_node)
> > +/* if matching fragment found return reassembled skb
> > + otherwise buffer the fragment */
>
> Could you change the first three spaces to a " * ". Otherwise checkpatch.pl is
> unhappy again.
>
> thanks,
> Sven
thanks, andreas
prev parent reply other threads:[~2010-09-12 1:14 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-10 16:47 [B.A.T.M.A.N.] batman-adv: unicast fragmentation enhancements Andreas Langer
2010-09-10 16:48 ` [B.A.T.M.A.N.] [PATCH] batman-adv: layer2 unicast packet " Andreas Langer
2010-09-11 9:26 ` Sven Eckelmann
2010-09-11 23:56 ` Marek Lindner
2010-09-12 20:11 ` Sven Eckelmann
2010-09-13 15:45 ` Andreas Langer
2010-09-12 1:14 ` Andreas Langer [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100912031448.6f7b11f7@rechenknecht \
--to=an.langer@gmx.de \
--cc=b.a.t.m.a.n@lists.open-mesh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.