On Tue, 10 Nov 2020 09:21:53 -0500 Jeff Dike wrote:
> > Perhaps it would make sense to widen the API to any "computed" address
> > rather than implicitly depending on this behavior for mcast?
>
> I'm happy to do that, but I don't know of any other types of
> addresses which are computed and end
On 11/10/20 7:21 AM, Jeff Dike wrote:
> Hi Jakub,
>
> On 11/9/20 2:47 PM, Jakub Kicinski wrote:
>> This makes sense because mcast L2 addr is calculated, not discovered,
>> and therefore can be recreated at a very low cost, correct?
>
> Yes.
>
>> Perhaps it would make sense to widen the API to an
Hi David,
On 11/9/20 10:55 PM, David Ahern wrote:
> ipv6_addr_type() and IPV6_ADDR_MULTICAST is the better way to code this.
Thanks, will fix.
Jeff
Hi Jakub,
On 11/9/20 2:47 PM, Jakub Kicinski wrote:
> This makes sense because mcast L2 addr is calculated, not discovered,
> and therefore can be recreated at a very low cost, correct?
Yes.
> Perhaps it would make sense to widen the API to any "computed" address
> rather than implicitly dependi
in addition to Jakub's comments ...
On 11/8/20 7:50 PM, Jeff Dike wrote:
> @@ -1706,6 +1708,11 @@ static void pndisc_redo(struct sk_buff *skb)
> kfree_skb(skb);
> }
>
> +static int ndisc_is_multicast(const void *pkey)
> +{
> + return (((struct in6_addr *)pkey)->in6_u.u6_addr8[0] & 0xf
On Sun, 8 Nov 2020 21:50:52 -0500 Jeff Dike wrote:
> Commit 58956317c8de ("neighbor: Improve garbage collection")
> guarantees neighbour table entries a five-second lifetime. Processes
> which make heavy use of multicast can fill the neighour table with
> multicast addresses in five seconds. At t
Commit 58956317c8de ("neighbor: Improve garbage collection")
guarantees neighbour table entries a five-second lifetime. Processes
which make heavy use of multicast can fill the neighour table with
multicast addresses in five seconds. At that point, neighbour entries
can't be GC-ed because they ar
