- 13 Nov, 2016 9 commits
-
-
Jiri Benc authored
It's not allowed to push Ethernet header in front of another Ethernet header. It's not allowed to pop Ethernet header if there's a vlan tag. This preserves the invariant that L3 packet never has a vlan tag. Based on previous versions by Lorand Jakab and Simon Horman. Signed-off-by:
Lorand Jakab <lojakab@cisco.com> Signed-off-by:
Simon Horman <simon.horman@netronome.com> Signed-off-by:
Jiri Benc <jbenc@redhat.com> Acked-by:
Pravin B Shelar <pshelar@ovn.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Jiri Benc authored
Extend the ovs flow netlink protocol to support L3 packets. Packets without OVS_KEY_ATTR_ETHERNET attribute specify L3 packets; for those, the OVS_KEY_ATTR_ETHERTYPE attribute is mandatory. Push/pop vlan actions are only supported for Ethernet packets. Based on previous versions by Lorand Jakab and Simon Horman. Signed-off-by:
-
Jiri Benc authored
Support receiving, extracting flow key and sending of L3 packets (packets without an Ethernet header). Note that even after this patch, non-Ethernet interfaces are still not allowed to be added to bridges. Similarly, netlink interface for sending and receiving L3 packets to/from user space is not in place yet. Based on previous versions by Lorand Jakab and Simon Horman. Signed-off-by:
-
Jiri Benc authored
Update Ethernet header only if there is one. Signed-off-by:
-
Jiri Benc authored
We'll need it to alter packets sent to ARPHRD_NONE interfaces. Change do_output() to use the actual L2 header size of the packet when deciding on the minimum cutlen. The assumption here is that what matters is not the output interface hard_header_len but rather the L2 header of the particular packet. For example, ARPHRD_NONE tunnels that encapsulate Ethernet should get at least the Ethernet header. Signed-off-by:
-
Jiri Benc authored
Use a hole in the structure. We support only Ethernet so far and will add a support for L2-less packets shortly. We could use a bool to indicate whether the Ethernet header is present or not but the approach with the mac_proto field is more generic and occupies the same number of bytes in the struct, while allowing later extensibility. It also makes the code in the next patches more self explaining. It would be nice to use ARPHRD_ constants but those are u16 which would be waste. Thus define our own constants. Another upside of this is that we can overload this new field to also denote whether the flow key is valid. This has the advantage that on refragmentation, we don't have to reparse the packet but can rely on the stored eth.type. This is especially important for the next patches in this series - instead of adding another branch for L2-less packets before calling ovs_fragment, we can just remove all those branches completely. Signed-off-by:
-
Jiri Benc authored
On tx, use hard_header_len while deciding whether to refragment or drop the packet. That way, all combinations are calculated correctly: * L2 packet going to L2 interface (the L2 header len is subtracted), * L2 packet going to L3 interface (the L2 header is included in the packet lenght), * L3 packet going to L3 interface. Signed-off-by:
-
Daniel Borkmann authored
Commit 67f8b1dc ("net/mlx4_en: Refactor the XDP forwarding rings scheme") added a bug in that the prog's reference count is not dropped in the error path when mlx4_en_try_alloc_resources() is failing from mlx4_xdp_set(). We previously took bpf_prog_add(prog, priv->rx_ring_num - 1), that we need to release again. Earlier in the call path, dev_change_xdp_fd() itself holds a reference to the prog as well (hence the '- 1' in the bpf_prog_add()), so a simple atomic_sub() is safe to use here. When an error is propagated, then bpf_prog_put() is called eventually from dev_change_xdp_fd() Fixes: 67f8b1dc ("net/mlx4_en: Refactor the XDP forwarding rings scheme") Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Acked-by:
Alexei Starovoitov <ast@kernel.org> Signed-off-by:
-
Ivan Khoronzhuk authored
While create/destroy channel operation memory is not freed. It was supposed that memory is freed while driver remove. But a channel can be created and destroyed many times while changing number of channels with ethtool. Based on net-next/master Signed-off-by:
Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org> Reviewed-by:
Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by:
-
- 10 Nov, 2016 31 commits
-
-
David S. Miller authored
Salil Mehta says: ==================== Bug fixes & Code improvements in HNS driver This patch-set introduces some bug fixes and code improvements. These have been identified during internal review or testing of the driver by internal Hisilicon teams. ==================== Signed-off-by: -
Kejian Yan authored
This patch adds the support to add or remove the unicast entries to the table and remove from the table. Reported-by:
Daode Huang <huangdaode@hisilicon.com> Signed-off-by:
Kejian Yan <yankejian@huawei.com> Reviewed-by:
Yisen Zhuang <yisen.zhuang@huawei.com> Signed-off-by:
Salil Mehta <salil.mehta@huawei.com> Signed-off-by:
-
Kejian Yan authored
There is no clear operation before add a new multicast tcam table, so the tcam table will be overflow when add more entries. Reported-by:
-
Qianqian Xie authored
The packets of wrong mac address(only the last bit is different) can be received in Big-endian by current definition of mask_key. Thus it needs to be modified to support Big-endian and ensure Big-endian normal. Signed-off-by:
Qianqian Xie <xieqianqian@huawei.com> Reviewed-by:
-
Qianqian Xie authored
The current definition of mac_mc_entry is only suitable for Little-endian. Thus it needs to modify tcam table of mac mc-entry to support both Little-endian and Big-endian. Signed-off-by:
-
Qianqian Xie authored
Little-endian is only supported by current tcam table to add or delete mac mc-port. This patch makes it support both Little-endian and Big-endian. Signed-off-by:
-
Qianqian Xie authored
Big-endian is not supported by the current definition of table index to get mac entry. It needs to be modified to support both Little-endian and Big-endian. Signed-off-by:
-
Qianqian Xie authored
The current definition of mac_uc_entry is only suitable for Little-endian. Thus it needs to modify tcam table of mac uc-entry to support both Little-endian and Big-endian. Signed-off-by:
-
Qianqian Xie authored
The current definition of dsaf_drv_tbl_tcam_key is only suitable for Little-endian. If data is stored in Big-endian, this may lead to error in data use. Shift operation can make it work normally in both Big-endian and Little-endian. Signed-off-by:
-
Qianqian Xie authored
Hardware ring buffer data is stored in Little-endian. Thus cpu data should be modified to Little-endian. Signed-off-by:
-
Daode Huang authored
In current scenario, when the interface is disabled we reset the XGMAC RX/TX functionality. This operation does not affects the PHY layer/SFP and which appears UP to the remote end(this behaviour is unlike GMAC). The result is remote end keeps on sending the packets which gets partly processed by XMAC and dropped. Since these are partly processed these appears as errored packets in the packet counter statistics. This patch fixes this behaviour and adds local-fault and remote-fault functionality which can be used to intimate the remote peer whenever the state of the interface changes. This patch also removes the existing hns_dsaf_xge_core_srst_by_port function which was being used to reset the RX/TX functionality at XGE Core. Reported-by:
Jun He <hjat2005@huawei.com> Signed-off-by:
-
Qianqian Xie authored
This patch modify the gmac_rx_filt_pkt and gmac_rx_octets_total_filt statistics value. The two statistics is inconsistent with register, and just the opposite. Signed-off-by:
-
Qianqian Xie authored
This patch deletes redundant macro definitions in hns drivers. And change the .h file containing relation to make the layers more clearly Signed-off-by:
Weiwei Deng <dengweiwei@huawei.com> Reviewed-by:
-
Daode Huang authored
When set auto-negotiation off and duplex half, if run "ethtool -r ethX" on port with phy, then the port will be failed to work. It should forbid to start auto-negotiation when auto-negotiate is off. This patch add the limited condition. Reported-by:
Jinchuang Tian <tianjinchuang1@huawei.com> Signed-off-by:
lipeng <lipeng321@huawei.com> Signed-off-by:
-
Daode Huang authored
The default mac pause time set to 0xff which is too short for pausing, this patch change it to the max value 0xffff. Signed-off-by:
-
Kejian Yan authored
If set promisc mode when there is some traffic, The service nic will cause system halted. We reserve the last 6 tcam entry for the 6 ports. If promisc mode is enabled, we can config the relative tcam as fuzzy matching and set to be valid, or set the tcam to be invalid Signed-off-by:
-
Kejian Yan authored
Since there is not enough tcam table entries for vlan and multicast address, HNSv2 needs to add support of fuzzy matching of TCAM tables. To add fuzzy match of TCAM, we Add the property to mask the bits to be fuzzy matched Signed-off-by:
-
Kejian Yan authored
Since there is not enough tcam table entries for every vlan and multicast address, HNS needs to add support of fuzzy matching of TCAM tables. Adding the property to mask the bits to be fuzzy matched, so update the bindings document Signed-off-by:
-
Eric Dumazet authored
After commit 6ed46d12 ("sock_diag: align nlattr properly when needed"), tcp_get_info() gets 64bit aligned memory, so we can avoid the unaligned helpers. Suggested-by:
Eric Dumazet <edumazet@google.com> Acked-by:
Soheil Hassas Yeganeh <soheil@google.com> Acked-by:
Yuchung Cheng <ycheng@google.com> Signed-off-by:
-
git://git.open-mesh.org/linux-mergeDavid S. Miller authored
Simon Wunderlich says: ==================== pull request for net-next: batman-adv 2016-11-08 v2 This feature and cleanup patchset includes the following changes: - netlink and code cleanups by Sven Eckelmann (3 patches) - Cleanup and minor fixes by Linus Luessing (3 patches) - Speed up multicast update intervals, by Linus Luessing - Avoid (re)broadcast in meshes for some easy cases, by Linus Luessing - Clean up tx return state handling, by Sven Eckelmann (6 patches) - Fix some special mac address handling cases, by Sven Eckelmann (3 patches) ==================== Signed-off-by: -
David S. Miller authored
Richard Cochran says: ==================== PHC frequency fine tuning This series expands the PTP Hardware Clock subsystem by adding a method that passes the frequency tuning word to the the drivers without dropping the low order bits. Keeping those bits is useful for drivers whose frequency resolution is higher than 1 ppb. The appended script (below) runs a simple demonstration of the improvement. This test needs two Intel i210 PCIe cards installed in the same PC, with their SDP0 pins connected by copper wire. Measuring the estimated offset (from the ptp4l servo) and the true offset (from the PPS) over one hour yields the following statistics. | | Est. Before | Est. After | True Before | True After | |--------+---------------+---------------+---------------+---------------| | min | -5.200000e+01 | -1.600000e+01 | -3.100000e+01 | -1.000000e+00 | | max | +5.700000e+01 | +2.500000e+01 | +8.500000e+01 | +4.000000e+01 | | pk-pk: | +1.090000e+02 | +4.100000e+01 | +1.160000e+02 | +4.100000e+01 | | mean | +6.472222e-02 | +1.277778e-02 | +2.422083e+01 | +1.826083e+01 | | stddev | +1.158006e+01 | +4.581982e+00 | +1.207708e+01 | +4.981435e+00 | Here the numbers in units of nanoseconds, and the ~20 nanosecond PPS offset is due to input/output delays on the i210's external interface logic. With the series applied, both the peak to peak error and the standard deviation improve by a factor of more than two. These two graphs show the improvement nicely. http://linuxptp.sourceforge.net/fine-tuning/fine-est.png http://linuxptp.sourceforge.net/fine-tuning/fine-tru.png ==================== Signed-off-by:
-
Richard Cochran authored
The dp83640 has a frequency resolution of about 0.029 ppb. This patch lets users of the device benefit from the increased frequency resolution when tuning the clock. Signed-off-by:
Richard Cochran <richardcochran@gmail.com> Signed-off-by:
-
Richard Cochran authored
The 82580 and related devices offer a frequency resolution of about 0.029 ppb. This patch lets users of the device benefit from the increased frequency resolution when tuning the clock. Signed-off-by:
-
Richard Cochran authored
The internal PTP Hardware Clock (PHC) interface limits the resolution for frequency adjustments to one part per billion. However, some hardware devices allow finer adjustment, and making use of the increased resolution improves synchronization measurably on such devices. This patch adds an alternative method that allows finer frequency tuning by passing the scaled ppm value to PHC drivers. This value comes from user space, and it has a resolution of about 0.015 ppb. We also deprecate the older method, anticipating its removal once existing drivers have been converted over. Signed-off-by:
Ulrik De Bie <ulrik.debie-os@e2big.org> Signed-off-by:
-
Eric Dumazet authored
There are no more users except from net/core/dev.c napi_hash_add() can now be static. Signed-off-by:
-
Eric Dumazet authored
This is automatically done from netif_napi_add(), and we want to not export napi_hash_add() anymore in the following patch. Signed-off-by:
Michael Chan <michael.chan@broadcom.com> Signed-off-by:
-
Tobias Klauser authored
Remove the unused but set variables min_set and max_set in adjust_reg_min_max_vals to fix the following warning when building with 'W=1': kernel/bpf/verifier.c:1483:7: warning: variable ‘min_set’ set but not used [-Wunused-but-set-variable] There is no warning about max_set being unused, but since it is only used in the assignment of min_set it can be removed as well. They were introduced in commit 48461135 ("bpf: allow access into map value arrays") but seem to have never been used. Cc: Josef Bacik <jbacik@fb.com> Signed-off-by:
Tobias Klauser <tklauser@distanz.ch> Acked-by:
-
Yotam Gigi authored
tc_act macro addressed a non existing field, and was not used in the kernel source. Signed-off-by:
Yotam Gigi <yotamg@mellanox.com> Reviewed-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
-
David S. Miller authored
David Lebrun says: ==================== net: add support for IPv6 Segment Routing v5: - Check SRH validity when adding a new route with lwtunnels and when setting an IPV6_RTHDR socket option. - Check that hdr->segments_left is not out of bounds when processing an SR-enabled packet. - Add __ro_after_init attribute to seg6_genl_policy structure. - Add CONFIG_IPV6_SEG6_INLINE option to enable or disable direct header insertion. v4: - Change @cleanup in ipv6_srh_rcv() from int to bool - Move checksum helper functions into header file - Add common definition for SR TLVs - Add comments for HMAC computation algorithm - Use rhashtable to store HMAC infos instead of linked list - Remove packed attribute for struct sr6_tlv_hmac - Use dst cache only if CONFIG_DST_CACHE is enabled v3: - Fix compilation for CONFIG_IPV6={n,m} v2: - Remove packed attribute from sr6 struct and replaced unaligned 16-bit flags with two 8-bit flags. - SR code now included by default. Option CONFIG_IPV6_SEG6_HMAC exists for HMAC support (which requires crypto dependencies). - Replace "hidden" calls to mutex_{un,}lock to direct calls. - Fix reverse xmas tree coding style. - Fix cast-from-void*'s. - Update skb->csum to account for SR modifications. - Add dst_cache in seg6_output. Segment Routing (SR) is a source routing paradigm, architecturally defined in draft-ietf-spring-segment-routing-09 [1]. The IPv6 flavor of SR is defined in draft-ietf-6man-segment-routing-header-02 [2]. The main idea is that an SR-enabled packet contains a list of segments, which represent mandatory waypoints. Each waypoint is called a segment endpoint. The SR-enabled packet is routed normally (e.g. shortest path) between the segment endpoints. A node that inserts an SRH into a packet is called an ingress node, and a node that is the last segment endpoint is called an egress node. From an IPv6 viewpoint, an SR-enabled packet contains an IPv6 extension header, which is a Routing Header type 4, defined as follows: struct ipv6_sr_hdr { __u8 nexthdr; __u8 hdrlen; __u8 type; __u8 segments_left; __u8 first_segment; __u8 flag_1; __u8 flag_2; __u8 reserved; struct in6_addr segments[0]; }; The first 4 bytes of the SRH is consistent with the Routing Header definition in RFC 2460. The type is set to `4' (SRH). Each segment is encoded as an IPv6 address. The segments are encoded in reverse order: segments[0] is the last segment of the path, and segments[first_segment] is the first segment of the path. segments[segments_left] points to the currently active segment and segments_left is decremented at each segment endpoint. There exist two ways for a packet to receive an SRH, we call them encap mode and inline mode. In the encap mode, the packet is encapsulated in an outer IPv6 header that contains the SRH. The inner (original) packet is not modified. A virtual tunnel is thus created between the ingress node (the node that encapsulates) and the egress node (the last segment of the path). Once an encapsulated SR packet reaches the egress node, the node decapsulates the packet and performs a routing decision on the inner packet. This kind of SRH insertion is intended to use for routers that encapsulates in-transit packet. The second SRH insertion method, the inline mode, acts by directly inserting the SRH right after the IPv6 header of the original packet. For this method, if a particular flag (SR6_FLAG_CLEANUP) is set, then the penultimate segment endpoint must strip the SRH from the packet before forwarding it to the last segment endpoint. This insertion method is intended to use for endhosts, however it is also used for in-transit packets by some industry actors. Note that directly inserting extension headers may break several mechanisms such as Path MTU Discovery, IPSec AH, etc. For this reason, this insertion method is only available if CONFIG_IPV6_SEG6_INLINE is enabled. Finally, the SRH may contain TLVs after the segments list. Several types of TLVs are defined, but we currently consider only the HMAC TLV. This TLV is an answer to the deprecation of the RH0 and enables to ensure the authenticity and integrity of the SRH. The HMAC text contains the flags, the first_segment index, the full list of segments, and the source address of the packet. While SR is intended to use mostly within a single administrative domain, the HMAC TLV allows to verify SR packets coming from an untrusted source. This patches series implements support for the IPv6 flavor of SR and is logically divided into the following components: (1) Data plane support (patch 01). This patch adds a function in net/ipv6/exthdrs.c to handle the Routing Header type 4. It enables the kernel to act as a segment endpoint, by supporting the following operations: decrementation of the segments_left field, cleanup flag support (removal of the SRH if we are the penultimate segment endpoint) and decapsulation of the inner packet as an egress node. (2) Control plane support (patches 02..03 and 07..09). These patches enables to insert SRH on locally emitted and/or forwarded packets, both with encap mode and with inline mode. The SRH insertion is controlled through the lightweight tunnels mechanism. Furthermore, patch 08 enables the applications to insert an SRH on a per-socket basis, through the setsockopt() system call. The mechanism to specify a per-socket Routing Header was already defined for RH0 and no special modification was performed on this side. However, the code to actually push the RH onto the packets had to be adapted for the SRH specifications. (3) HMAC support (patches 04..06). These patches adds the support of the HMAC TLV verification for the dataplane part, and generation for the control plane part. Two hashing algorithms are supported (SHA-1 as legacy and SHA-256 as required by the IETF draft), but additional algorithms can be easily supported by simply adding an entry into an array. [1] https://tools.ietf.org/html/draft-ietf-spring-segment-routing-09 [2] https://tools.ietf.org/html/draft-ietf-6man-segment-routing-header-02 ==================== Signed-off-by: -
David Lebrun authored
This patch adds documentation for some SR-related per-interface sysctls. Signed-off-by:
David Lebrun <david.lebrun@uclouvain.be> Signed-off-by:
-
David Lebrun authored
This patch adds support for per-socket SRH injection with the setsockopt system call through the IPPROTO_IPV6, IPV6_RTHDR options. The SRH is pushed through the ipv6_push_nfrag_opts function. Signed-off-by:
-
