[Differential] [Changed Subscribers] D1388: IP6: Turned on verbose logging for fragment handling code

ae added a subscriber: ae. ae added a comment. I think you need to adjust some comments in frag6_input(). REVISION DETAIL https://reviews.freebsd.org/D1388 To: kibab, bz Cc: ae, freebsd-net ___ freebsd-net@freebsd.org mailing list http://lists.freebs

[Differential] [Changed Subscribers] D1777: Associated fix for arp/nd6 timer usage.

ae added a subscriber: ae. ae added a comment. You said about some panics, do you have traces? REVISION DETAIL https://reviews.freebsd.org/D1777 To: rrs, imp, sbruno, gnn, rwatson, lstewart, kostikbel, adrian, jhb, bz Cc: ae, bz, emaste, hiren, julian, hselasky, freebsd-net ___

[Differential] [Changed Subscribers] D1815: Evaluate packet size after the firewall had its chance

ae added a subscriber: ae. ae added a comment. Since you are in ip6_forward(), this means ip6_input() has already checked this packet and PFIL had a chance to handle this packet. IPv6 router should not do reassembling fragmented packets and do new fragmentation of them, but if you want, I think

[Differential] [Accepted] D1764: Factor out ip6_deletefraghdr()

ae added a subscriber: ae. ae accepted this revision. ae added a reviewer: ae. ae added a comment. I have no objections against it, the code looks similar to previous implementation. REVISION DETAIL https://reviews.freebsd.org/D1764 To: kristof, glebius, ae Cc: ae, glebius, freebsd-net __

[Differential] [Changed Subscribers] D1986: Teach lagg(4) to change MTU

ae added a subscriber: ae. ae added a comment. Just a thought. Imagine two interfaces, one has maximum MTU 2200, another 1500. lagg0 has MTU 1400. Two threads invokes changing MTU in the same time. One wants to change it to 2000, another - to 1500. It is possible, that when both threads will fin

[Differential] [Commented On] D1986: Teach lagg(4) to change MTU

ae added a comment. >>! In D1986#7, @rstone wrote: > RLOCK only gets a read lock. You want WLOCK to get a write lock to ensure > serialization. Also we can use another lock in the lagg_ioctl, that will prevent simultaneous MTU changing. REVISION DETAIL https://reviews.freebsd.org/D1986 To:

[Differential] D12457: Complete INADDR_HASH lock protection

ae added inline comments. INLINE COMMENTS > eugen_grosbein.net wrote in if_stf.c:383 > in_localip() may be better, I just wished to make the patch as clear as > possible minizing changes for first revision. Using in_localip() is preferred, because INADDR_HASH is protected with rmlock only in h

[Differential] D8214: ifnet: Use if_link_state snapshot to invoke ifnet_link_event

ae accepted this revision. ae added a reviewer: ae. ae added a comment. This revision has a positive review. Looks ok to me. REVISION DETAIL https://reviews.freebsd.org/D8214 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: sepherosa_gmail.com, glebius,

[Differential] D9451: Constrain IPv6 interface routes to each FIB

ae added a comment. Can you resubmit the patch with more context? You can make it using such arguments for svn diff "--diff-cmd=diff -x -U99" or similar arguments for your VCS. It produces a much large patches, but it is possible to see more context. REPOSITORY rS FreeBSD src reposito

[Differential] D23737: nat64: Get the IPv4 address from a NAT64 address when comparing addresses in a ICMP translate

ae requested changes to this revision. ae added a comment. This revision now requires changes to proceed. The patch is not correct. IPv4 address can be embedded in different places depending from configuration. REPOSITORY rS FreeBSD src repository CHANGES SINCE LAST ACTION https://review

[Differential] D23737: nat64: Get the IPv4 address from a NAT64 address when comparing addresses in a ICMP translate

ae added a comment. In D23737#521593 , @neel_neelc.org wrote: > Here, I also compare the destination addresses. Is this what you want? No, take a look at RFC 6052 p2.2. . REPOSITORY rS Fre

[Differential] D23737: nat64: Get the IPv4 address from a NAT64 address when comparing addresses in a ICMP translate

ae added a comment. Also, how did test your changes? :) NAT64 currently is not widely used, thus changes here can break something and you will know about breakage when it will be not so easy to fix, e.g. after release. REPOSITORY rS FreeBSD src repository CHANGES SINCE LAST ACTION ht

[Differential] D24061: Hyper-V socket implementation for FreeBSD guest

ae added a comment. Do you have performance test results for already existing linux implementation? From a quick look it seems to me there will be bottleneck regarding locking that seems can be reduced using CK and epoch. But this task can be done in future, if you plan support this code.

[Differential] D24989: netinet: Generate a random RSS key on boot.

ae added a comment. In D24989#552576 , @avg wrote: > I have a vague memory, maybe wrong, that commonly used fixed RSS keys were selected because they had some property (-ies). > So, maybe just being random is not good enough? > I think that h

[Differential] D26757: Fix to join AllHost mcast group again when adding an existing IP address

ae accepted this revision. ae added a comment. This revision is now accepted and ready to land. Looks correct to me. REPOSITORY rS FreeBSD src repository CHANGES SINCE LAST ACTION https://reviews.freebsd.org/D26757/new/ REVISION DETAIL https://reviews.freebsd.org/D26757 EMAIL PREFEREN

[Differential] D26757: Fix to join AllHost mcast group again when adding an existing IP address

This revision was automatically updated to reflect the committed changes. Closed by commit rS366682: Join to AllHosts multicast group again when adding an existing IPv4 address. (authored by ae). CHANGED PRIOR TO COMMIT https://reviews.freebsd.org/D26757?vs=78157&id=78184#toc REPOSITORY rS F