From: Stephan Gatzka <stephan.gatzka@gmail.com>
To: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>,
netdev@vger.kernel.org, linux1394-devel@lists.sourceforge.net
Subject: Re: IPv6 over Firewire
Date: Sat, 22 Dec 2012 19:33:14 +0100 [thread overview]
Message-ID: <50D5FCEA.9060406@gmail.com> (raw)
In-Reply-To: <20121222101521.08c783ac@stein>
>
> You could add another case to include/net/ndisc.h::ndisc_addr_option_pad()
> with a hardcoded size, couldn't you?
>
No, I think that is almost certainly not a good idea. The address space
option is handed over to the firewire_net driver like this:
type, length, soure/target link address (GUID)
If I add another case in ndisc_addr_option_pad() I think the option will
look like this:
pad, type, length, soure/target link address (GUID)
Because pad, type and GUID are already at the correct position for the
3146 link layer option. So with padding I have to copy them to the
correct position.
All I need is some (8 bytes) of additional tail room in the ndisc skb.
This could be achieved either by specifying needed_tailroom in the
firewire netdevice struct at the expense that now every skb allocated
might get 8 bytes more allocated.
The second option is yoshfuji suggestion to pimp ndisc_opt_addr_space a
bit. His solution only allocates additional memory for ndisc packets at
the expense to introduce a dependency to the struct
ndisc_opt_ieee1394_llinfo.
These are the two option we can go for. Personally I think reserving a
bit more tail room looks cleaner if nobody votes against it...
Regards,
Stephan
next prev parent reply other threads:[~2012-12-22 18:33 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-21 17:03 IPv6 over Firewire Stephan Gatzka
2012-12-21 17:53 ` YOSHIFUJI Hideaki
2012-12-21 18:39 ` Stephan Gatzka
2012-12-21 19:49 ` YOSHIFUJI Hideaki
2012-12-21 23:12 ` Stefan Richter
2012-12-22 6:03 ` Stephan Gatzka
2012-12-22 6:10 ` Stephan Gatzka
2012-12-22 9:15 ` Stefan Richter
2012-12-22 18:33 ` Stephan Gatzka [this message]
2012-12-23 8:23 ` YOSHIFUJI Hideaki
2012-12-23 11:13 ` Stephan Gatzka
2012-12-23 12:09 ` YOSHIFUJI Hideaki
2012-12-23 13:25 ` Stephan Gatzka
2012-12-23 17:09 ` YOSHIFUJI Hideaki
2012-12-23 18:25 ` Stephan Gatzka
2012-12-23 19:38 ` YOSHIFUJI Hideaki
2012-12-23 23:52 ` Stefan Richter
[not found] <50EF1AEB.1080704@gmail.com>
[not found] ` <50EFE095.2040505@linux-ipv6.org>
[not found] ` <50F10C53.4000803@gmail.com>
2013-01-12 8:27 ` IPv6 over firewire Stefan Richter
[not found] ` <20130110210912.09c62d38@stein>
[not found] ` <50F10E94.9090302@gmail.com>
2013-01-12 9:24 ` Stefan Richter
2013-01-12 10:54 ` Stephan Gatzka
2013-01-12 13:57 ` Stefan Richter
2013-01-12 14:37 ` Stefan Richter
2013-01-12 14:42 ` Stephan Gatzka
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=50D5FCEA.9060406@gmail.com \
--to=stephan.gatzka@gmail.com \
--cc=linux1394-devel@lists.sourceforge.net \
--cc=netdev@vger.kernel.org \
--cc=stefanr@s5r6.in-berlin.de \
--cc=yoshfuji@linux-ipv6.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.