[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-devel] [patch #7409] IPv6 support for LwIP 1.4.0RC1

From: Ivan Delamer
Subject: [lwip-devel] [patch #7409] IPv6 support for LwIP 1.4.0RC1
Date: Sun, 15 May 2011 16:25:41 +0000
User-agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0)

Follow-up Comment #9, patch #7409 (project lwip):


You bring up soem very good points. These came up when I was coding. Luckily,
this can be implemented in several ways. I'll explain the reasons why it was
done like this, but I think either way is almost as good.

1) One struct with v4/v6 flag, versus v4 struct and v6 struct. PArt of the
reason I went with two structs is memory, like you point out. In
32-bit-aligned architectures, a v4 address becomes 20 bytes. I'm also worried
about the impact that changing this would have on current applications. I went
with lesser impact to applications and larger impact to the stack. It can also
be reversed.

I also think that with the current approach, there is plenty of room to
optimize duplicate code. Right now I'm counting on the compiler optimize to
work it out.

As for netif->output, I don't think there is a way around having 2 functions
for v4 and v6. For v6 there is some extra information needed. Also, v4 will
usually go through ARP and v6 will go through ND. So we either have one
netif->output that then switches to ARP/ND, or we already do that ourselves
and save a step (and stack).

2) I agree that IPv6 adds a lot of #ifs. I'm not particularly creative with
macros, but I think that would be the way to go to make the code more compact
and legible.

If you think it would help, I can update the patch so that we can apply it to
1.4.0, it might take a couple of days since I have to book the time for this.



Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]