Re: [RFC] Exempt multicast address from five-second neighbor lifetime

[Jeff Dike <jdike@akamai.com>]

Hi Jesse,

> Your subject should indicate net or net-next as the tree, please see:

I was intending more to see if this is an intrinsically bad idea than for it to go directly into a tree right now.

> Not sure how many patches you've submitted, but your commit message
> should be wrapped at 68 or 72 characters or so.

Not my first patch, but the first sent through Thunderbird and Outlook.

> your triple-dash and a diffstat should be right here, did you hand edit
> this mail instead of using git format-patch to generate it?

Yup, the log message on my internal commit wouldn't make too much sense outside of Akamai, so I wrote this changelog in my MUA.
 
> Why is this added in the middle of the includes?

I needed to get IN_MULTICAST defined - this is one reason I don't expect this patch as it stands to go anywhere.  IN_MULTICAST seems intended just for userspace use, but there isn't any way to ask the same question in the kernel.  The same seems to be true of IPv6 multicast addresses.

>> +static int arp_is_multicast(const void *pkey)
>> +{
>> +	return IN_MULTICAST(htonl(*((u32 *) pkey)));
>> +}
> 
> Why not just move this function up and skip the declaration above?

Following existing practice in this file.  Similar functions are declared above the structure and defined below it.

>>  
>> +static int ndisc_is_multicast(const void *pkey)
>> +{
>> +	return (((struct in6_addr *) pkey)->in6_u.u6_addr8[0] & 0xf0) == 0xf0;
>> +}
>> +
> 
> Again, just move this up above the first usage?

Following existing practice again.
> 
> Does the above work on big and little endian, just seems suspicious
> even though you're using a byte offset? Also I suspect this will
> trigger a warning with sparse or with W=2 about pointer alignment.

I used the byte offsets on purpose for this reason.  Didn't check if sparse had any problems with it.

Jeff