- 18 Jul, 2017 12 commits
-
-
Vivien Didelot authored
The 88E6352 family supports Energy Detect and has one bit for Sense and one bit for periodically transmit NLP (Energy Detect+TM). The 88E6390 family adds another bit to distinguish Auto or SW wake-up. Chips supporting EEE all have an EEE Enabled bit in the Port Status Register. This patch adds new ops for the PHY Energy Detect accesses. This also allows us to get rid of the MV88E6XXX_FLAG_EEE flag. Signed-off-by:
Vivien Didelot <vivien.didelot@savoirfairelinux.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Vivien Didelot authored
Similarly to global1_addr, add a global2_addr member in the info structure to describe the presence of the Global 2 Registers. This allows us to get rid of the MV88E6XXX_FLAG_GLOBAL2 flag. Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Vivien Didelot authored
Add a pot_clear operation to clear the Priority Override Table and wrap its call into a mv88e6xxx_pot_setup helper. This allows us to get rid of the MV88E6XXX_FLAG_G2_POT flag. Signed-off-by:
-
Vivien Didelot authored
The 88E6390 family clear the Priority Override Table the same way as 88E6352, thus add MV88E6XXX_FLAG_G2_POT to MV88E6XXX_FLAGS_FAMILY_6390. Signed-off-by:
-
Vivien Didelot authored
The 88E6185 family only has one 16-bit register to mark the 16 802.1D reserved multicast addresses in the range of 01:80:C2:00:00:0x as MGMT. The 88E6352 family also has one 16-bit register to mark the 16 GARP reserved multicast addresses in the range of 01:80:C2:00:00:2x as MGMT. Split the existing mv88e6095 prefixed mgmt_rsvd2cpu operation into two distinct mv88e6185 and mv88e6352 prefixed operations, and wrap its call into a mv88e6xxx_rsvd2cpu_setup helper. This allows us to also get rid of the MV88E6XXX_CAP_G2_MGMT_EN_* flags. Signed-off-by:
-
Vivien Didelot authored
Similarly to g1_irqs, add a g2_irqs member to the info structure to indicates the presence of the Global 2 Interrupt Source and Mask registers. At the same time, provide helpers and document the registers since they differ a bit between 88E6352 and 88E6390 families. This allows us to get rid of the MV88E6XXX_FLAG_G2_INT flag. Signed-off-by:
-
Vivien Didelot authored
The 88E6185 family has no Global 2 Interrupt Source or Mask registers. Remove the MV88E6XXX_FLAG_G2_INT from MV88E6XXX_FLAGS_FAMILY_6185. Signed-off-by:
-
Vivien Didelot authored
Remove the forgotten capabilities and related flags from previous cleanups. Signed-off-by:
-
Vivien Didelot authored
MV88E6XXX_FAMILY_6321 is undefined, 88E6321's family is 88E6320, fix this. Signed-off-by:
-
Vivien Didelot authored
We don't support LED control yet, remove its register definition. Signed-off-by:
-
Vivien Didelot authored
phy.c does not need to include the DSA public header. Remove it. Signed-off-by:
-
John Fastabend authored
Initial patches missed case with CONFIG_BPF_SYSCALL not set. Fixes: 11393cc9 ("xdp: Add batching support to redirect map") Fixes: 97f91a7c ("bpf: add bpf_redirect_map helper routine") Signed-off-by:
John Fastabend <john.fastabend@gmail.com> Signed-off-by:
-
- 17 Jul, 2017 28 commits
-
-
Fabio Estevam authored
The gpiod API checks for NULL descriptors, so there is no need to duplicate the check in the driver. Signed-off-by:
Fabio Estevam <fabio.estevam@nxp.com> Reviewed-by:
-
Andy Gospodarek authored
When testing with a driver that has both native and generic redirect support: $ sudo ./samples/bpf/xdp_redirect -N 5 6 input: 5 output: 6 ifindex 6: 4961879 pkt/s ifindex 6: 6391319 pkt/s ifindex 6: 6419468 pkt/s $ sudo ./samples/bpf/xdp_redirect -S 5 6 input: 5 output: 6 ifindex 6: 1845435 pkt/s ifindex 6: 3882850 pkt/s ifindex 6: 3893974 pkt/s $ sudo ./samples/bpf/xdp_redirect_map -N 5 6 input: 5 output: 6 map[0] (vports) = 4, map[1] (map) = 5, map[2] (count) = 0 ifindex 6: 2207374 pkt/s ifindex 6: 6212869 pkt/s ifindex 6: 6286515 pkt/s $ sudo ./samples/bpf/xdp_redirect_map -S 5 6 input: 5 output: 6 map[0] (vports) = 4, map[1] (map) = 5, map[2] (count) = 0 ifindex 6: 5052528 pkt/s ifindex 6: 5736631 pkt/s ifindex 6: 5739962 pkt/s Signed-off-by:
Andy Gospodarek <andy@greyhouse.net> Acked-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
-
Arvind Yadav authored
pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by <linux/pci.h> work with const pci_device_id. So mark the non-const structs as const. File size before: text data bss dec hex filename 5113 384 0 5497 1579 drivers/net/ethernet/ec_bhf.o File size After adding 'const': text data bss dec hex filename 5177 320 0 5497 1579 drivers/net/ethernet/ec_bhf.o Signed-off-by:
Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by:
-
Arvind Yadav authored
pci_device_id are not supposed to change at runtime. All functions working with pci_device_id provided by <linux/pci.h> work with const pci_device_id. So mark the non-const structs as const. File size before: text data bss dec hex filename 791 336 0 1127 467 net/ethernet/cadence/macb_pci.o File size After adding 'const': text data bss dec hex filename 855 272 0 1127 467 net/ethernet/cadence/macb_pci.o Signed-off-by: -
Florian Westphal authored
It was added for netlink mmap tx, there are no callers in the tree. The commit also added a check for skb->head != NULL in kfree_skb path, remove that too -- all skbs ought to have skb->head set. Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
-
David S. Miller authored
David S. Miller says: ==================== net: Remove UDP Fragmentation Offload support This is a patch series, based upon some discussions with various developers, that removes UFO offloading. Very few devices support this operation, it's usefullness is quesitonable at best, and it adds a non-trivial amount of complexity to our data paths. v2: Delete more code thanks to feedback from Willem. ==================== Signed-off-by: -
David S. Miller authored
No longer used. Signed-off-by: -
David S. Miller authored
Rename udp{4,6}_ufo_fragment() to udp{4,6}_tunnel_segment() and only handle tunnel segmentation. Signed-off-by: -
David S. Miller authored
Such packets are no longer possible. Signed-off-by: -
David S. Miller authored
Signed-off-by: -
David S. Miller authored
It is going away. Signed-off-by: -
David S. Miller authored
It is going away. Signed-off-by: -
David S. Miller authored
It is going away. Signed-off-by: -
David S. Miller authored
It is going away. Signed-off-by: -
David S. Miller authored
It is going away. Signed-off-by: -
David S. Miller authored
It is going away. Signed-off-by: -
David S. Miller authored
It is going away. Signed-off-by: -
David S. Miller authored
This driver doesn't actually support UFO explicitly yet it advertises this in netdev->features. Signed-off-by: -
David S. Miller authored
Signed-off-by: -
David S. Miller authored
John Fastabend says: ==================== Implement XDP bpf_redirect This series adds two new XDP helper routines bpf_redirect() and bpf_redirect_map(). The first variant bpf_redirect() is meant to be used the same way it is currently being used by the cls_bpf classifier. An xdp packet will be redirected immediately when this is called. The other variant bpf_redirect_map(map, key, flags) uses a new map type called devmap. A devmap uses integers as keys and net_devices as values. The user provies key/ifindex pairs to update the map with new net_devices. This provides two benefits over the normal variant 'bpf_redirect()'. First the datapath bpf program is abstracted away from using hard-coded ifindex values. Allowing a single bpf program to be run any many different environments. Second, and perhaps more important, the map enables batching packet transmits. The map plus small driver changes allows for batching all send requests across a NAPI poll loop. This allows driver writers to optimize the driver xmit path and only call expensive operations once for a batch of xdp_buffs. The devmap was designed to support possible future work for multicast and broadcast as follow-up patches. To see, in more detail, how to leverage the new helpers and map from the userspace side please review these two patches, xdp: sample program for new bpf_redirect helper xdp: bpf redirect with map sample program Performance numbers provided by Jesper are the following, tested using the ixgbe driver with CPU E5-1650 v4 @ 3.60GHz: 13,939,674 pkt/s = XDP_DROP without touching memory 14,290,650 pkt/s = xdp1: XDP_DROP with reading packet data 13,221,812 pkt/s = xdp2: XDP_TX with swap mac (writes into pkt) 7,596,576 pkt/s = xdp_redirect: XDP_REDIRECT with swap mac (like XDP_TX) 13,058,435 pkt/s = xdp_redirect_map:XDP_REDIRECT with swap mac + devmap A big thanks to everyone who helped with this series. Jesper provided fixes, debugging, code review, performance benchmarks! Daniel provided lots of useful feedback and code review. And last but not least Andy provided useful feedback related to supporting additional drivers, generic xdp implementation, testing, etc. Any other feedback is welcome but I believe at this point these are ready to be merged! Whats left... get the rest of the drivers developers to implement this in all the drivers. ==================== Signed-off-by: -
John Fastabend authored
Signed-off-by:
Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by:
-
John Fastabend authored
The BPF map devmap holds a refcnt on the net_device structure when it is in the map. We need to do this to ensure on driver unload we don't lose a dev reference. However, its not very convenient to have to manually unload the map when destroying a net device so add notifier handlers to do the cleanup automatically. But this creates a race between update/destroy BPF syscall and programs and the unregister netdev hook. Unfortunately, the best I could come up with is either to live with requiring manual removal of net devices from the map before removing the net device OR to add a mutex in devmap to ensure the map is not modified while we are removing a device. The fallout also requires that BPF programs no longer update/delete the map from the BPF program side because the mutex may sleep and this can not be done from inside an rcu critical section. This is not a real problem though because I have not come up with any use cases where this is actually useful in practice. If/when we come up with a compelling user for this we may need to revisit this. Signed-off-by:
-
John Fastabend authored
For performance reasons we want to avoid updating the tail pointer in the driver tx ring as much as possible. To accomplish this we add batching support to the redirect path in XDP. This adds another ndo op "xdp_flush" that is used to inform the driver that it should bump the tail pointer on the TX ring. Signed-off-by:
-
John Fastabend authored
BPF programs can use the devmap with a bpf_redirect_map() helper routine to forward packets to netdevice in map. Signed-off-by:
-
John Fastabend authored
Device map (devmap) is a BPF map, primarily useful for networking applications, that uses a key to lookup a reference to a netdevice. The map provides a clean way for BPF programs to build virtual port to physical port maps. Additionally, it provides a scoping function for the redirect action itself allowing multiple optimizations. Future patches will leverage the map to provide batching at the XDP layer. Another optimization/feature, that is not yet implemented, would be to support multiple netdevices per key to support efficient multicast and broadcast support. Signed-off-by:
-
John Fastabend authored
This adds a trace event for xdp redirect which may help when debugging XDP programs that use redirect bpf commands. Signed-off-by:
-
John Fastabend authored
There are optimizations we can add after the basic feature is enabled. But, for now keep the patch simple. Signed-off-by:
-
John Fastabend authored
Add support for redirect to xdp generic creating a fall back for devices that do not yet have support and allowing test infrastructure using veth pairs to be built. Signed-off-by:
-
