***SPAM***会议记录【太 陽 城集团：401362。COM 送 您150%老 虎] 机大牌优 惠,存100送100 二存再送50 元，天天反水2.0%起，
Thank you for your e-mail. Tech-Line S.A will be closed for summer holidays from August 6th to Friday August 25th inclusive. I will reply to your e-mail upon my return. Best regards, Athina Mathioudaki
[PATCH][net-next] vxlan: reduce dirty cache line in vxlan_find_mac
vxlan_find_mac() unconditionally set f->used for every packet, this cause a cache miss for every packet, since remote, hlist and used of vxlan_fdb share the same cacheline. With this change f->used is set only if not equal to jiffies This gives up to 5% speed-up with small packets. Signed-off-by: Zhang Yu Signed-off-by: Li RongQing --- drivers/net/vxlan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c index ababba37d735..e5d236595206 100644 --- a/drivers/net/vxlan.c +++ b/drivers/net/vxlan.c @@ -464,7 +464,7 @@ static struct vxlan_fdb *vxlan_find_mac(struct vxlan_dev *vxlan, struct vxlan_fdb *f; f = __vxlan_find_mac(vxlan, mac, vni); - if (f) + if (f && f->used != jiffies) f->used = jiffies; return f; -- 2.16.2
Re: [RFC 0/1] Appletalk AARP probe broken by receipt of own broadcasts.
On 19/08/18 13:32, Andrew Lunn wrote: On Sun, Aug 19, 2018 at 01:07:38PM +1200, Craig McGeachie wrote: I'm hoping I can find someone able and willing to test this patch. That requires someone still using netatalk 2.2.x with DDP, or some other DDP userspace application. This feels like a longshot. When netatalk 2.2.x starts up with DDP and sets the Appletalk node address, the kernel AARP code sends a probe packet for the address. It then receives its own probe packet and interprets that as some other node also trying to claim the address. It increments the address, tries again, and fails again ad nausium. Eventually the kernel module gives up and returns to netatalk which terminates with an error that it cannot get a node address. Hi Craig What Ethernet device are you seeing this problem with? I'm not sure an Ethernet device should receive its own broadcasts. This might be a driver bug, not an AARP bug. Andrew I run inside Virtualbox with the Realtek PCIe GBE Family Controller. Assuming I'm reading /sys/class/net/enp0s3/driver correctly, it's using the e1000 driver. However, it might not be the ethernet driver's fault. I've been a bit loose with terminology. Appletalk AARP probe packets aren't ethernet broadcasts as such; they're multicast packets, via the psnap driver, to hardware address 09:00:07:ff:ff:ff. Cheers, Craig.
Re: [RFC 0/1] Appletalk AARP probe broken by receipt of own broadcasts.
On Sun, Aug 19, 2018 at 01:07:38PM +1200, Craig McGeachie wrote: > I'm hoping I can find someone able and willing to test this patch. That > requires someone still using netatalk 2.2.x with DDP, or some other DDP > userspace application. This feels like a longshot. > > When netatalk 2.2.x starts up with DDP and sets the Appletalk node > address, the kernel AARP code sends a probe packet for the address. It > then receives its own probe packet and interprets that as some other > node also trying to claim the address. It increments the address, tries > again, and fails again ad nausium. Eventually the kernel module gives up > and returns to netatalk which terminates with an error that it cannot > get a node address. Hi Craig What Ethernet device are you seeing this problem with? I'm not sure an Ethernet device should receive its own broadcasts. This might be a driver bug, not an AARP bug. Andrew
[RFC 1/1] appletalk: ignore aarp probe broadcasts that loopback.
AARP probe packets are broadcast to dynamically discover if an Appletalk
node address is in use. The definition of AARP requires interpreting the
receipt of probe requests for the address being tested as the address being
in use, and then trying the next address. However, the node receives its own
Ethertalk broadcast, and incorrectly interprets that as another node trying
to claim the address.
Signed-off-by: Craig McGeachie
---
net/appletalk/aarp.c | 4
1 file changed, 4 insertions(+)
diff --git a/net/appletalk/aarp.c b/net/appletalk/aarp.c
index 49a16cee..f966cc01 100644
--- a/net/appletalk/aarp.c
+++ b/net/appletalk/aarp.c
@@ -757,6 +757,10 @@ static int aarp_rcv(struct sk_buff *skb, struct net_device
*dev,
if (!ifa)
goto out1;
+ /* Ignore packets from myself. */
+ if (ether_addr_equal(ea->hw_src, dev->dev_addr))
+ goto out1;
+
if (ifa->status & ATIF_PROBE &&
ifa->address.s_node == ea->pa_dst_node &&
ifa->address.s_net == ea->pa_dst_net) {
--
2.17.1
[RFC 0/1] Appletalk AARP probe broken by receipt of own broadcasts.
I'm hoping I can find someone able and willing to test this patch. That requires someone still using netatalk 2.2.x with DDP, or some other DDP userspace application. This feels like a longshot. When netatalk 2.2.x starts up with DDP and sets the Appletalk node address, the kernel AARP code sends a probe packet for the address. It then receives its own probe packet and interprets that as some other node also trying to claim the address. It increments the address, tries again, and fails again ad nausium. Eventually the kernel module gives up and returns to netatalk which terminates with an error that it cannot get a node address. Well, most of the time. There seems to be some sort of race condition where occasionally a self collision won't happen. Restart netatalk enough times and it will probably work. The device Ethernet MAC address is copied into the AARP packet, so the fix is to disregard all received packets that have a sender address that matches the device hardware address. This is more than just probe packets, but there is no legitimate situation where an Appletalk node sends AARP packets to itself. Craig McGeachie (1): appletalk: ignore aarp probe broadcasts that loopback. net/appletalk/aarp.c | 4 1 file changed, 4 insertions(+) -- 2.17.1
financial support
-- donation of $3 to you, contact hams@hotmail.com to verefly
Re: [PATCH ethtool] ethtool: document WoL filters option also in help message
On Fri, Aug 17, 2018 at 10:51:31AM -0700, Florian Fainelli wrote:
> On 08/17/2018 06:21 AM, Michal Kubecek wrote:
> > Commit eff0bb337223 ("ethtool: Add support for WAKE_FILTER (WoL using
> > filters)") added option "f" for wake on lan and documented it in man page
> > but not in the output of "ethtool --help".
> >
> > Signed-off-by: Michal Kubecek
>
> Acked-by: Florian Fainelli
>
> Thanks Michal!
Yes, good eye!
John
--
John W. LinvilleSomeday the world will need a hero, and you
linvi...@tuxdriver.com might be all we have. Be ready.
Re: [PATCH]ipv6: multicast: In mld_send_cr function moving read lock to second for loop
From: Guruswamy Basavaiah Date: Fri, 17 Aug 2018 18:01:41 +0530 > @@ -1860,7 +1860,6 @@ static void mld_send_cr(struct inet6_dev *idev) > struct sk_buff *skb = NULL; > int type, dtype; > > -read_lock_bh(>lock); > spin_lock(>mc_lock); > > /* deleted MCA's */ This will lead to deadlocks, idev->mc_lock must be taken with _bh(). I have zero confidence in this change, did you do any stress testing with lockdep enabled? It would have caught this quickly.
Re: how to (cross)connect two (physical) eth ports for ping test?
On Sat, Aug 18, 2018 at 09:10:25PM +0200, Andrew Lunn wrote: > On Sat, Aug 18, 2018 at 01:39:50PM -0400, Robert P. J. Day wrote: > > > > (i'm sure this has been explained many times before, so a link > > covering this will almost certainly do just fine.) > > > > i want to loop one physical ethernet port into another, and just > > ping the daylights from one to the other for stress testing. my fedora > > laptop doesn't actually have two unused ethernet ports, so i just want > > to emulate this by slapping a couple startech USB/net adapters into > > two empty USB ports, setting this up, then doing it all over again > > monday morning on the actual target system, which does have multiple > > ethernet ports. > > > > so if someone can point me to the recipe, that would be great and > > you can stop reading. > > > > as far as my tentative solution goes, i assume i need to put at > > least one of the physical ports in a network namespace via "ip netns", > > then ping from the netns to the root namespace. or, going one step > > further, perhaps putting both interfaces into two new namespaces, and > > setting up forwarding. > > Namespaces is a good solution. Something like this should work: > > ip netns add namespace1 > ip netns add namespace2 > > ip link set eth1 netns namespace1 > ip link set eth2 netns namespace2 > > ip netns exec namespace1 \ > ip addr add 10.42.42.42/24 dev eth1 > > ip netns exec namespace1 \ > ip link set eth1 up > > ip netns exec namespace2 \ > ip addr add 10.42.42.24/24 dev eth2 > > ip netns exec namespace2 \ > ip link set eth2 up > > ip netns exec namespace1 \ > ping 10.42.42.24 > > You might also want to consider iperf3 for stress testing, depending > on the sort of stress you need. FWIW I have a setup somewhere involving ip rule + ip route which achieves the same without involving namespaces. It's a bit hackish but sometimes convenient. I can dig if someone is interested. Regards, Willy
Re: [bpf-next RFC 2/3] flow_dissector: implements eBPF parser
On Sat, Aug 18, 2018 at 11:56 AM Tom Herbert wrote:
>
> On Thu, Aug 16, 2018 at 9:44 AM, Petar Penkov wrote:
> > From: Petar Penkov
> >
> > This eBPF program extracts basic/control/ip address/ports keys from
> > incoming packets. It supports recursive parsing for IP
> > encapsulation, MPLS, GUE, and VLAN, along with IPv4/IPv6 and extension
> > headers. This program is meant to show how flow dissection and key
> > extraction can be done in eBPF.
> >
> > It is initially meant to be used for demonstration rather than as a
> > complete replacement of the existing flow dissector.
> >
> > This includes parsing of GUE and MPLS payload, which cannot be done
> > in production in general, as GUE tunnels and MPLS payloads cannot
> > unambiguously be detected in general.
> >
> > In closed environments, however, it can be enabled. Another example
> > where the programmability of BPF aids flow dissection.
> > +static __always_inline int write_ports(struct __sk_buff *skb, __u8 proto)
> > +{
> > + struct bpf_dissect_cb *cb = (struct bpf_dissect_cb *)(skb->cb);
> > + struct flow_dissector_key_ports ports;
> > +
> > + /* The supported protocols always start with the ports */
> > + if (bpf_skb_load_bytes(skb, cb->nhoff, , sizeof(ports)))
> > + return BPF_DROP;
> > +
> > + if (proto == IPPROTO_UDP && ports.dst == bpf_htons(GUE_PORT)) {
> > + /* GUE encapsulation */
> > + cb->nhoff += sizeof(struct udphdr);
> > + bpf_tail_call(skb, _table, GUE);
> > + return BPF_DROP;
>
> It's a nice sentiment to support GUE, but this really isn't the right
> way to do it.
Yes, this was just for demonstration purposes. The same for
unconditionally parsing MPLS payload as IP.
Though note the point in the commit message that within a closed
network with fixed reserved GUE ports, a custom BPF program
like this could be sufficient. That's true not only for UDP tunnels.
> What would be much better is a means to generically
> support all the various UDP encapsulations like GUE, VXLAN, Geneve,
> GRE/UDP, MPLS/UDP, etc. I think there's two ways to do that:
>
> 1) A UDP socket lookup that returns an encapsulation socket containing
> a flow dissector function that can be called. This is the safest
> method because of the UDP are reserved numbers problem. I implement
> this in kernel flow dissector, not upstreamed though.
Yes, similar to udp_gro_receive. Socket lookup is not free, however,
and this is a relatively rarely used feature.
I want to move the one in udp_gro_receive behind a static key.
udp_encap_needed_key is the likely target. Then the same can
eventually be done for flow dissection inside UDP tunnels.
> 2) Create a lookup table based on destination port that returns the
> flow dissector function to call. This doesn't have the socket lookup
> so it isn't quite as robust as the socket lookup. But, at least it's a
> generic interface and programmable so it might be appropriate in the
> BPF flow dissector case.
Option 1 sounds preferable to me.
Re: how to (cross)connect two (physical) eth ports for ping test?
On Sat, Aug 18, 2018 at 01:39:50PM -0400, Robert P. J. Day wrote: > > (i'm sure this has been explained many times before, so a link > covering this will almost certainly do just fine.) > > i want to loop one physical ethernet port into another, and just > ping the daylights from one to the other for stress testing. my fedora > laptop doesn't actually have two unused ethernet ports, so i just want > to emulate this by slapping a couple startech USB/net adapters into > two empty USB ports, setting this up, then doing it all over again > monday morning on the actual target system, which does have multiple > ethernet ports. > > so if someone can point me to the recipe, that would be great and > you can stop reading. > > as far as my tentative solution goes, i assume i need to put at > least one of the physical ports in a network namespace via "ip netns", > then ping from the netns to the root namespace. or, going one step > further, perhaps putting both interfaces into two new namespaces, and > setting up forwarding. Namespaces is a good solution. Something like this should work: ip netns add namespace1 ip netns add namespace2 ip link set eth1 netns namespace1 ip link set eth2 netns namespace2 ip netns exec namespace1 \ ip addr add 10.42.42.42/24 dev eth1 ip netns exec namespace1 \ ip link set eth1 up ip netns exec namespace2 \ ip addr add 10.42.42.24/24 dev eth2 ip netns exec namespace2 \ ip link set eth2 up ip netns exec namespace1 \ ping 10.42.42.24 You might also want to consider iperf3 for stress testing, depending on the sort of stress you need. Andrew
how to (cross)connect two (physical) eth ports for ping test?
(i'm sure this has been explained many times before, so a link covering this will almost certainly do just fine.) i want to loop one physical ethernet port into another, and just ping the daylights from one to the other for stress testing. my fedora laptop doesn't actually have two unused ethernet ports, so i just want to emulate this by slapping a couple startech USB/net adapters into two empty USB ports, setting this up, then doing it all over again monday morning on the actual target system, which does have multiple ethernet ports. so if someone can point me to the recipe, that would be great and you can stop reading. as far as my tentative solution goes, i assume i need to put at least one of the physical ports in a network namespace via "ip netns", then ping from the netns to the root namespace. or, going one step further, perhaps putting both interfaces into two new namespaces, and setting up forwarding. anyway, a recipe for this would be just ducky. thank you kindly. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca/dokuwiki Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday
Re: [PATCH] net: nixge: Add support for 64-bit platforms
From: Moritz Fischer Date: Thu, 16 Aug 2018 12:07:06 -0700 > Add support for 64-bit platforms to driver. > > The hardware only supports 32-bit register accesses > so the accesses need to be split up into two writes > when setting the current and tail descriptor values. > > Cc: Florian Fainelli > Signed-off-by: Moritz Fischer Please resubmit when the net-next tree opens back up. Thank you.
Re: pull-request: bpf 2018-08-18
From: Daniel Borkmann Date: Sat, 18 Aug 2018 01:29:20 +0200 > The following pull-request contains BPF updates for your *net* tree. > > The main changes are: ... > Please consider pulling these changes from: > > git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git Pulled, thanks.
Re: [bpf-next RFC 2/3] flow_dissector: implements eBPF parser
On Thu, Aug 16, 2018 at 9:44 AM, Petar Penkov wrote:
> From: Petar Penkov
>
> This eBPF program extracts basic/control/ip address/ports keys from
> incoming packets. It supports recursive parsing for IP
> encapsulation, MPLS, GUE, and VLAN, along with IPv4/IPv6 and extension
> headers. This program is meant to show how flow dissection and key
> extraction can be done in eBPF.
>
> It is initially meant to be used for demonstration rather than as a
> complete replacement of the existing flow dissector.
>
> This includes parsing of GUE and MPLS payload, which cannot be done
> in production in general, as GUE tunnels and MPLS payloads cannot
> unambiguously be detected in general.
>
> In closed environments, however, it can be enabled. Another example
> where the programmability of BPF aids flow dissection.
>
> Link: http://vger.kernel.org/netconf2017_files/rx_hardening_and_udp_gso.pdf
> Signed-off-by: Petar Penkov
> Signed-off-by: Willem de Bruijn
> ---
> tools/testing/selftests/bpf/Makefile | 2 +-
> tools/testing/selftests/bpf/bpf_flow.c | 542 +
> 2 files changed, 543 insertions(+), 1 deletion(-)
> create mode 100644 tools/testing/selftests/bpf/bpf_flow.c
>
> diff --git a/tools/testing/selftests/bpf/Makefile
> b/tools/testing/selftests/bpf/Makefile
> index fff7fb1285fc..e65f50f9185e 100644
> --- a/tools/testing/selftests/bpf/Makefile
> +++ b/tools/testing/selftests/bpf/Makefile
> @@ -35,7 +35,7 @@ TEST_GEN_FILES = test_pkt_access.o test_xdp.o test_l4lb.o
> test_tcp_estats.o test
> test_get_stack_rawtp.o test_sockmap_kern.o test_sockhash_kern.o \
> test_lwt_seg6local.o sendmsg4_prog.o sendmsg6_prog.o
> test_lirc_mode2_kern.o \
> get_cgroup_id_kern.o socket_cookie_prog.o
> test_select_reuseport_kern.o \
> - test_skb_cgroup_id_kern.o
> + test_skb_cgroup_id_kern.o bpf_flow.o
>
> # Order correspond to 'make run_tests' order
> TEST_PROGS := test_kmod.sh \
> diff --git a/tools/testing/selftests/bpf/bpf_flow.c
> b/tools/testing/selftests/bpf/bpf_flow.c
> new file mode 100644
> index ..9c11c644b713
> --- /dev/null
> +++ b/tools/testing/selftests/bpf/bpf_flow.c
> @@ -0,0 +1,542 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "bpf_helpers.h"
> +#include "bpf_endian.h"
> +
> +int _version SEC("version") = 1;
> +#define PROG(F) SEC(#F) int bpf_func_##F
> +
> +/* These are the identifiers of the BPF programs that will be used in tail
> + * calls. Name is limited to 16 characters, with the terminating character
> and
> + * bpf_func_ above, we have only 6 to work with, anything after will be
> cropped.
> + */
> +enum {
> + IP,
> + IPV6,
> + IPV6OP, /* Destination/Hop-by-Hop Options IPv6 Extension header */
> + IPV6FR, /* Fragmentation IPv6 Extension Header */
> + MPLS,
> + VLAN,
> + GUE,
> +};
> +
> +#define IP_MF 0x2000
> +#define IP_OFFSET 0x1FFF
> +#define IP6_MF 0x0001
> +#define IP6_OFFSET 0xFFF8
> +
> +struct vlan_hdr {
> + __be16 h_vlan_TCI;
> + __be16 h_vlan_encapsulated_proto;
> +};
> +
> +struct gre_hdr {
> + __be16 flags;
> + __be16 proto;
> +};
> +
> +#define GUE_PORT 6080
> +/* Taken from include/net/gue.h. Move that to uapi, instead? */
> +struct guehdr {
> + union {
> + struct {
> +#if defined(__LITTLE_ENDIAN_BITFIELD)
> + __u8hlen:5,
> + control:1,
> + version:2;
> +#elif defined (__BIG_ENDIAN_BITFIELD)
> + __u8version:2,
> + control:1,
> + hlen:5;
> +#else
> +#error "Please fix "
> +#endif
> + __u8proto_ctype;
> + __be16 flags;
> + };
> + __be32 word;
> + };
> +};
> +
> +enum flow_dissector_key_id {
> + FLOW_DISSECTOR_KEY_CONTROL, /* struct flow_dissector_key_control */
> + FLOW_DISSECTOR_KEY_BASIC, /* struct flow_dissector_key_basic */
> + FLOW_DISSECTOR_KEY_IPV4_ADDRS, /* struct
> flow_dissector_key_ipv4_addrs */
> + FLOW_DISSECTOR_KEY_IPV6_ADDRS, /* struct
> flow_dissector_key_ipv6_addrs */
> + FLOW_DISSECTOR_KEY_PORTS, /* struct flow_dissector_key_ports */
> + FLOW_DISSECTOR_KEY_ICMP, /* struct flow_dissector_key_icmp */
> + FLOW_DISSECTOR_KEY_ETH_ADDRS, /* struct flow_dissector_key_eth_addrs
> */
> + FLOW_DISSECTOR_KEY_TIPC, /* struct flow_dissector_key_tipc */
> + FLOW_DISSECTOR_KEY_ARP, /* struct flow_dissector_key_arp */
> + FLOW_DISSECTOR_KEY_VLAN, /* struct flow_dissector_key_flow_vlan */
> + FLOW_DISSECTOR_KEY_FLOW_LABEL, /* struct flow_dissector_key_flow_tags
>
