* [PATCH v4 bpf-next 1/7] selftests/bpf: rename flow dissector section to flow_dissector
From: Stanislav Fomichev @ 2018-11-09 0:22 UTC (permalink / raw)
To: netdev, linux-kselftest, ast, daniel, shuah, jakub.kicinski,
quentin.monnet
Cc: guro, jiong.wang, sdf, bhole_prashant_q7, john.fastabend, jbenc,
treeze.taeung, yhs, osk, sandipan
In-Reply-To: <20181109002213.5914-1-s@fomichev.me>
From: Stanislav Fomichev <sdf@google.com>
Makes it compatible with the logic that derives program type
from section name in libbpf_prog_type_by_name.
Signed-off-by: Stanislav Fomichev <sdf@google.com>
---
tools/testing/selftests/bpf/bpf_flow.c | 2 +-
tools/testing/selftests/bpf/test_flow_dissector.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/bpf/bpf_flow.c b/tools/testing/selftests/bpf/bpf_flow.c
index 107350a7821d..b9798f558ca7 100644
--- a/tools/testing/selftests/bpf/bpf_flow.c
+++ b/tools/testing/selftests/bpf/bpf_flow.c
@@ -116,7 +116,7 @@ static __always_inline int parse_eth_proto(struct __sk_buff *skb, __be16 proto)
return BPF_DROP;
}
-SEC("dissect")
+SEC("flow_dissector")
int _dissect(struct __sk_buff *skb)
{
if (!skb->vlan_present)
diff --git a/tools/testing/selftests/bpf/test_flow_dissector.sh b/tools/testing/selftests/bpf/test_flow_dissector.sh
index c0fb073b5eab..d23d4da66b83 100755
--- a/tools/testing/selftests/bpf/test_flow_dissector.sh
+++ b/tools/testing/selftests/bpf/test_flow_dissector.sh
@@ -59,7 +59,7 @@ else
fi
# Attach BPF program
-./flow_dissector_load -p bpf_flow.o -s dissect
+./flow_dissector_load -p bpf_flow.o -s flow_dissector
# Setup
tc qdisc add dev lo ingress
--
2.19.1.930.g4563a0d9d0-goog
^ permalink raw reply related
* [PATCH v4 bpf-next 0/7] bpftool: support loading flow dissector
From: Stanislav Fomichev @ 2018-11-09 0:22 UTC (permalink / raw)
To: netdev, linux-kselftest, ast, daniel, shuah, jakub.kicinski,
quentin.monnet
Cc: guro, jiong.wang, sdf, bhole_prashant_q7, john.fastabend, jbenc,
treeze.taeung, yhs, osk, sandipan
From: Stanislav Fomichev <sdf@google.com>
v4 changes:
* addressed another round of comments/style issues from Jakub Kicinski &
Quentin Monnet (thanks!)
* implemented bpf_object__pin_maps and bpf_object__pin_programs helpers and
used them in bpf_program__pin
* added new pin_name to bpf_program so bpf_program__pin
works with sections that contain '/'
* moved *loadall* command implementation into a separate patch
* added patch that implements *pinmaps* to pin maps when doing
load/loadall
v3 changes:
* (maybe) better cleanup for partial failure in bpf_object__pin
* added special case in bpf_program__pin for programs with single
instances
v2 changes:
* addressed comments/style issues from Jakub Kicinski & Quentin Monnet
* removed logic that populates jump table
* added cleanup for partial failure in bpf_object__pin
This patch series adds support for loading and attaching flow dissector
programs from the bpftool:
* first patch fixes flow dissector section name in the selftests (so
libbpf auto-detection works)
* second patch adds proper cleanup to bpf_object__pin, parts of which are now
being used to attach all flow dissector progs/maps
* third patch adds special case in bpf_program__pin for programs with
single instances (we don't create <prog>/0 pin anymore, just <prog>)
* forth patch adds pin_name to the bpf_program struct
which is now used as a pin name in bpf_program__pin et al
* fifth patch adds *loadall* command that pins all programs, not just
the first one
* sixth patch adds *pinmaps* argument to load/loadall to let users pin
all maps of the obj file
* seventh patch adds actual flow_dissector support to the bpftool and
an example
Stanislav Fomichev (7):
selftests/bpf: rename flow dissector section to flow_dissector
libbpf: cleanup after partial failure in bpf_object__pin
libbpf: bpf_program__pin: add special case for instances.nr == 1
libbpf: add internal pin_name
bpftool: add loadall command
bpftool: add pinmaps argument to the load/loadall
bpftool: support loading flow dissector
.../bpftool/Documentation/bpftool-prog.rst | 42 +-
tools/bpf/bpftool/bash-completion/bpftool | 21 +-
tools/bpf/bpftool/common.c | 31 +-
tools/bpf/bpftool/main.h | 1 +
tools/bpf/bpftool/prog.c | 185 ++++++---
tools/lib/bpf/libbpf.c | 364 ++++++++++++++++--
tools/lib/bpf/libbpf.h | 18 +
tools/testing/selftests/bpf/bpf_flow.c | 2 +-
.../selftests/bpf/test_flow_dissector.sh | 2 +-
9 files changed, 546 insertions(+), 120 deletions(-)
--
2.19.1.930.g4563a0d9d0-goog
^ permalink raw reply
* Re: [PATCH net-next 0/7] net: sched: prepare for more Qdisc offloads
From: David Miller @ 2018-11-09 0:20 UTC (permalink / raw)
To: jakub.kicinski
Cc: netdev, oss-drivers, jiri, xiyou.wangcong, jhs, nogah.frankel,
yuvalm
In-Reply-To: <20181108013340.20983-1-jakub.kicinski@netronome.com>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Wed, 7 Nov 2018 17:33:33 -0800
> This series refactors the "switchdev" Qdisc offloads a little. We have
> a few Qdiscs which can be fully offloaded today to the forwarding plane
> of switching devices.
>
> First patch adds a helper for handing statistic dumps, the code seems
> to be copy pasted between PRIO and RED. Second patch removes unnecessary
> parameter from RED offload function. Third patch makes the MQ offload
> use the dump helper which helps it behave much like PRIO and RED when
> it comes to the TCQ_F_OFFLOADED flag. Patch 4 adds a graft helper,
> similar to the dump helper.
>
> Patch 5 is unrelated to offloads, qdisc_graft() code seemed ripe for a
> small refactor - no functional changes there.
>
> Last two patches move the qdisc_put() call outside of the sch_tree_lock
> section for RED and PRIO. The child Qdiscs will get removed from the
> hierarchy under the lock, but having the put (and potentially destroy)
> called outside of the lock helps offload which may choose to sleep,
> and it should generally lower the Qdisc change impact.
Series applied, thanks Jakub.
^ permalink raw reply
* Re: [PATCH net] net: mvneta: Don't advertise 2.5G modes
From: Russell King - ARM Linux @ 2018-11-09 9:57 UTC (permalink / raw)
To: Maxime Chevallier
Cc: davem, netdev, linux-kernel, Antoine Tenart, thomas.petazzoni,
gregory.clement, Andrew Lunn, linux-arm-kernel
In-Reply-To: <20181109081733.24458-1-maxime.chevallier@bootlin.com>
On Fri, Nov 09, 2018 at 09:17:33AM +0100, Maxime Chevallier wrote:
> Using 2.5G speed relies on the SerDes lanes being configured
> accordingly. The lanes have to be reconfigured to switch between
> 1G and 2.5G, and for now only the bootloader does this configuration.
>
> In the case we add a Comphy driver to handle switching the lanes
> dynamically, it's better for now to stick with supporting only 1G and
> add advertisement for 2.5G once we really are capable of handling both
> speeds without problem.
>
> Since the interface mode is initialy taken from the DT, we want to make
> sure that adding comphy support won't break boards that don't update
> their dtb.
>
> Fixes: da58a931f248 ("net: mvneta: Add support for 2500Mbps SGMII")
> Reported-by: Andrew Lunn <andrew@lunn.ch>
> Reported-by: Russell King <linux@armlinux.org.uk>
> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
As we discussed on IRC... however, please can we wait until Monday/
Tuesday before merging this patch to allow for some further thought
and discussion - by which time I expect to have a comphy driver.
Thanks.
> ---
> drivers/net/ethernet/marvell/mvneta.c | 12 +++---------
> 1 file changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
> index 5bfd349bf41a..c19ecd153499 100644
> --- a/drivers/net/ethernet/marvell/mvneta.c
> +++ b/drivers/net/ethernet/marvell/mvneta.c
> @@ -3343,7 +3343,6 @@ static void mvneta_validate(struct net_device *ndev, unsigned long *supported,
> if (state->interface != PHY_INTERFACE_MODE_NA &&
> state->interface != PHY_INTERFACE_MODE_QSGMII &&
> state->interface != PHY_INTERFACE_MODE_SGMII &&
> - state->interface != PHY_INTERFACE_MODE_2500BASEX &&
> !phy_interface_mode_is_8023z(state->interface) &&
> !phy_interface_mode_is_rgmii(state->interface)) {
> bitmap_zero(supported, __ETHTOOL_LINK_MODE_MASK_NBITS);
> @@ -3357,14 +3356,9 @@ static void mvneta_validate(struct net_device *ndev, unsigned long *supported,
> /* Asymmetric pause is unsupported */
> phylink_set(mask, Pause);
>
> - /* We cannot use 1Gbps when using the 2.5G interface. */
> - if (state->interface == PHY_INTERFACE_MODE_2500BASEX) {
> - phylink_set(mask, 2500baseT_Full);
> - phylink_set(mask, 2500baseX_Full);
> - } else {
> - phylink_set(mask, 1000baseT_Full);
> - phylink_set(mask, 1000baseX_Full);
> - }
> + /* Half-duplex at speeds higher than 100Mbit is unsupported */
> + phylink_set(mask, 1000baseT_Full);
> + phylink_set(mask, 1000baseX_Full);
>
> if (!phy_interface_mode_is_8023z(state->interface)) {
> /* 10M and 100M are only supported in non-802.3z mode */
> --
> 2.11.0
>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* Re: [RFC PATCH 0/3] acpi: Add acpi mdio support code
From: Andrew Lunn @ 2018-11-08 23:23 UTC (permalink / raw)
To: Wang Dongsheng; +Cc: timur, yu.zheng, f.fainelli, rjw, linux-acpi, netdev
In-Reply-To: <cover.1541660504.git.dongsheng.wang@hxt-semitech.com>
On Thu, Nov 08, 2018 at 03:21:29PM +0800, Wang Dongsheng wrote:
> Originally I just push "phy-handle" support for ACPI on the QCOM QDF2400
> platform. After some discussion and following Andrew's advice, I send
> out with a generic version of ACPI.
>
> Current there is no clear documentation about MDIO/PHY for ACPI, so when
> I reading some documents about ACPI [1], I think we just need to reuse the
> DT binding in the ACPI.[2]. However, this series of patches are not
> fully compatible with all contents specified in DT binding.
>
> The most important thing about this iseries is link the phy device and
> fwnode of acpi. Besides, we need to carry out bus scan at the mdio
> register. Therefore, I am not compatible with more DT binding properties
> in this series of patches. More support will be in the follow-up patches
> support, or some people do the support.
>
> Example:
> Based on ACPI doc:
> Documentation/acpi/dsd/data-node-references.txt
> Documentation/acpi/dsd/graph.txt
> With _DSD device properties we can finally do this:
> Device (MDIO) {
> Name (_DSD, Package () {
> ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
> Package () { Package () { "ethernet-phy@0", PHY0 }, }
> })
> Name (PHY0, Package() {
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () { Package () { "reg", 0x0 }, }
> })
I don't know much about ACPI. I do know DT. MDIO busses can have
multiple PHYs on them. Is the following valid to list two PHYs?
Device (MDIO) {
Name (_DSD, Package () {
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
Package () { Package () { "ethernet-phy@0", PHY0 }, }
})
Name (PHY0, Package() {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () { Package () { "reg", 0x0 }, }
})
Name (_DSD, Package () {
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
Package () { Package () { "ethernet-phy@10", PHY1 }, }
})
Name (PHY1, Package() {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () { Package () { "reg", 0x10 }, }
})
}
An MDIO bus can also have more than PHYs on them. There can be
Ethernet switches. Broadcom also have some with generic PHY devices on
them, and other odd things. That means whatever is on an MDIO bus is a
device in the Linux device model. How does that work? Do we need some
form Device (PHY) {}?
Device (MDIO) {
Device (PHY) {
Name (_DSD, Package () {
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
Package () { Package () { "ethernet-phy@0", PHY0 }, }
})
Name (PHY0, Package() {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () { Package () { "reg", 0x0 }, }
})
}
Device (PHY) {
Name (_DSD, Package () {
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
Package () { Package () { "ethernet-phy@10", PHY1 }, }
})
Name (PHY1, Package() {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () { Package () { "reg", 0x10 }, }
})
Device (SWITCH) {
Name (_DSD, Package () {
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
Package () { Package () { "switch@11", SWITCH0 }, }
})
Name (SWITCH0, Package() {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () { Package () { "reg", 0x11 }, }
})
}
}
I'm just trying to ensure whatever is defined is flexible enough that
we really can later support everything which DT does. We have PHYs on
MDIO busses, inside switches, which are on MDIO busses, which are
inside Ethernet interfaces, etc.
An MDIO bus is very similar to an i2c bus. How is that described in
ACPI? Anything we can learn from that?
Thanks
Andrew
^ permalink raw reply
* [PATCH net-next 9/9] sky2: use __vlan_hwaccel helpers
From: Michał Mirosław @ 2018-11-08 23:18 UTC (permalink / raw)
To: netdev
Cc: Mirko Lindner, Stephen Hemminger, Ajit Khaparde, Alexey Kuznetsov,
bridge, Cong Wang, coreteam, David S. Miller, Florian Westphal,
Hideaki YOSHIFUJI, Jamal Hadi Salim, Jiri Pirko, Jozsef Kadlecsik,
linux-rdma, netfilter-devel, Nikolay Aleksandrov,
Pablo Neira Ayuso, Roopa Prabhu, Sathya Perla,
Somnath Kotur <somnath.
In-Reply-To: <cover.1541718583.git.mirq-linux@rere.qmqm.pl>
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
drivers/net/ethernet/marvell/sky2.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/marvell/sky2.c b/drivers/net/ethernet/marvell/sky2.c
index 697d9b374f5e..c7cd0081058e 100644
--- a/drivers/net/ethernet/marvell/sky2.c
+++ b/drivers/net/ethernet/marvell/sky2.c
@@ -2485,13 +2485,11 @@ static struct sk_buff *receive_copy(struct sky2_port *sky2,
skb->ip_summed = re->skb->ip_summed;
skb->csum = re->skb->csum;
skb_copy_hash(skb, re->skb);
- skb->vlan_proto = re->skb->vlan_proto;
- skb->vlan_tci = re->skb->vlan_tci;
+ __vlan_hwaccel_copy_tag(skb, re->skb);
pci_dma_sync_single_for_device(sky2->hw->pdev, re->data_addr,
length, PCI_DMA_FROMDEVICE);
- re->skb->vlan_proto = 0;
- re->skb->vlan_tci = 0;
+ __vlan_hwaccel_clear_tag(re->skb);
skb_clear_hash(re->skb);
re->skb->ip_summed = CHECKSUM_NONE;
skb_put(skb, length);
--
2.19.1
^ permalink raw reply related
* [PATCH net-next 7/9] benet: use __vlan_hwaccel helpers
From: Michał Mirosław @ 2018-11-08 23:18 UTC (permalink / raw)
To: netdev
Cc: Sathya Perla, Ajit Khaparde, Sriharsha Basavapatna, Somnath Kotur,
Alexey Kuznetsov, bridge, Cong Wang, coreteam, David S. Miller,
Florian Westphal, Hideaki YOSHIFUJI, Jamal Hadi Salim, Jiri Pirko,
Jozsef Kadlecsik, linux-rdma, Mirko Lindner, netfilter-devel,
Nikolay Aleksandrov, Pablo Neira Ayuso, Roopa
In-Reply-To: <cover.1541718583.git.mirq-linux@rere.qmqm.pl>
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
drivers/net/ethernet/emulex/benet/be_main.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index c5ad7a4f4d83..80b2bd3747ce 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -1049,30 +1049,35 @@ static struct sk_buff *be_insert_vlan_in_pkt(struct be_adapter *adapter,
struct be_wrb_params
*wrb_params)
{
+ bool insert_vlan = false;
u16 vlan_tag = 0;
skb = skb_share_check(skb, GFP_ATOMIC);
if (unlikely(!skb))
return skb;
- if (skb_vlan_tag_present(skb))
+ if (skb_vlan_tag_present(skb)) {
vlan_tag = be_get_tx_vlan_tag(adapter, skb);
+ insert_vlan = true;
+ }
if (qnq_async_evt_rcvd(adapter) && adapter->pvid) {
- if (!vlan_tag)
+ if (!insert_vlan) {
vlan_tag = adapter->pvid;
+ insert_vlan = true;
+ }
/* f/w workaround to set skip_hw_vlan = 1, informs the F/W to
* skip VLAN insertion
*/
BE_WRB_F_SET(wrb_params->features, VLAN_SKIP_HW, 1);
}
- if (vlan_tag) {
+ if (insert_vlan) {
skb = vlan_insert_tag_set_proto(skb, htons(ETH_P_8021Q),
vlan_tag);
if (unlikely(!skb))
return skb;
- skb->vlan_tci = 0;
+ __vlan_hwaccel_clear_tag(skb);
}
/* Insert the outer VLAN, if any */
--
2.19.1
^ permalink raw reply related
* [PATCH net-next 8/9] mlx4: use __vlan_hwaccel helpers
From: Michał Mirosław @ 2018-11-08 23:18 UTC (permalink / raw)
To: netdev
Cc: Tariq Toukan, linux-rdma, Ajit Khaparde, Alexey Kuznetsov, bridge,
Cong Wang, coreteam, David S. Miller, Florian Westphal,
Hideaki YOSHIFUJI, Jamal Hadi Salim, Jiri Pirko, Jozsef Kadlecsik,
Mirko Lindner, netfilter-devel, Nikolay Aleksandrov,
Pablo Neira Ayuso, Roopa Prabhu, Sathya Perla, Somnath Kotur
In-Reply-To: <cover.1541718583.git.mirq-linux@rere.qmqm.pl>
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
index db00bf1c23f5..fd09ba98c0a6 100644
--- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
@@ -875,7 +875,7 @@ int mlx4_en_process_rx_cq(struct net_device *dev, struct mlx4_en_cq *cq, int bud
skb->data_len = length;
napi_gro_frags(&cq->napi);
} else {
- skb->vlan_tci = 0;
+ __vlan_hwaccel_clear_tag(skb);
skb_clear_hash(skb);
}
next:
--
2.19.1
^ permalink raw reply related
* [PATCH net-next 6/9] ipv4/tunnel: use __vlan_hwaccel helpers
From: Michał Mirosław @ 2018-11-08 23:18 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Alexey Kuznetsov, Hideaki YOSHIFUJI,
Ajit Khaparde, bridge, Cong Wang, coreteam, Florian Westphal,
Jamal Hadi Salim, Jiri Pirko, Jozsef Kadlecsik, linux-rdma,
Mirko Lindner, netfilter-devel, Nikolay Aleksandrov,
Pablo Neira Ayuso, Roopa Prabhu, Sathya Perla, Somnath Kotur,
Sriharsha Basavapatna <srih
In-Reply-To: <cover.1541718583.git.mirq-linux@rere.qmqm.pl>
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
net/ipv4/ip_tunnel_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/ip_tunnel_core.c b/net/ipv4/ip_tunnel_core.c
index dde671e97829..f45b96d715f0 100644
--- a/net/ipv4/ip_tunnel_core.c
+++ b/net/ipv4/ip_tunnel_core.c
@@ -120,7 +120,7 @@ int __iptunnel_pull_header(struct sk_buff *skb, int hdr_len,
}
skb_clear_hash_if_not_l4(skb);
- skb->vlan_tci = 0;
+ __vlan_hwaccel_clear_tag(skb);
skb_set_queue_mapping(skb, 0);
skb_scrub_packet(skb, xnet);
--
2.19.1
^ permalink raw reply related
* [PATCH net-next 5/9] bridge: use __vlan_hwaccel helpers
From: Michał Mirosław @ 2018-11-08 23:18 UTC (permalink / raw)
To: netdev
Cc: Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal,
Roopa Prabhu, Nikolay Aleksandrov, netfilter-devel, coreteam,
bridge, Ajit Khaparde, Alexey Kuznetsov, Cong Wang,
David S. Miller, Hideaki YOSHIFUJI, Jamal Hadi Salim, Jiri Pirko,
linux-rdma, Mirko Lindner, Sathya Perla, Somnath Kotur,
Sriharsha Basavapatna <srih
In-Reply-To: <cover.1541718583.git.mirq-linux@rere.qmqm.pl>
This removes assumption than vlan_tci != 0 when tag is present.
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
net/bridge/br_netfilter_hooks.c | 15 +++++++++------
net/bridge/br_private.h | 2 +-
net/bridge/br_vlan.c | 6 +++---
3 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/net/bridge/br_netfilter_hooks.c b/net/bridge/br_netfilter_hooks.c
index b1b5e8516724..c9383c470a83 100644
--- a/net/bridge/br_netfilter_hooks.c
+++ b/net/bridge/br_netfilter_hooks.c
@@ -671,10 +671,8 @@ static int br_nf_push_frag_xmit(struct net *net, struct sock *sk, struct sk_buff
return 0;
}
- if (data->vlan_tci) {
- skb->vlan_tci = data->vlan_tci;
- skb->vlan_proto = data->vlan_proto;
- }
+ if (data->vlan_proto)
+ __vlan_hwaccel_put_tag(skb, data->vlan_proto, data->vlan_tci);
skb_copy_to_linear_data_offset(skb, -data->size, data->mac, data->size);
__skb_push(skb, data->encap_size);
@@ -740,8 +738,13 @@ static int br_nf_dev_queue_xmit(struct net *net, struct sock *sk, struct sk_buff
data = this_cpu_ptr(&brnf_frag_data_storage);
- data->vlan_tci = skb->vlan_tci;
- data->vlan_proto = skb->vlan_proto;
+ if (skb_vlan_tag_present(skb)) {
+ data->vlan_tci = skb->vlan_tci;
+ data->vlan_proto = skb->vlan_proto;
+ } else {
+ data->vlan_proto = 0;
+ }
+
data->encap_size = nf_bridge_encap_header_len(skb);
data->size = ETH_HLEN + data->encap_size;
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index 2920e06a5403..67105c66584a 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -905,7 +905,7 @@ static inline int br_vlan_get_tag(const struct sk_buff *skb, u16 *vid)
int err = 0;
if (skb_vlan_tag_present(skb)) {
- *vid = skb_vlan_tag_get(skb) & VLAN_VID_MASK;
+ *vid = skb_vlan_tag_get_id(skb);
} else {
*vid = 0;
err = -EINVAL;
diff --git a/net/bridge/br_vlan.c b/net/bridge/br_vlan.c
index 8c9297a01947..a7e869da21bf 100644
--- a/net/bridge/br_vlan.c
+++ b/net/bridge/br_vlan.c
@@ -420,7 +420,7 @@ struct sk_buff *br_handle_vlan(struct net_bridge *br,
}
if (v->flags & BRIDGE_VLAN_INFO_UNTAGGED)
- skb->vlan_tci = 0;
+ __vlan_hwaccel_clear_tag(skb);
if (p && (p->flags & BR_VLAN_TUNNEL) &&
br_handle_egress_vlan_tunnel(skb, v)) {
@@ -493,8 +493,8 @@ static bool __allowed_ingress(const struct net_bridge *br,
__vlan_hwaccel_put_tag(skb, br->vlan_proto, pvid);
else
/* Priority-tagged Frame.
- * At this point, We know that skb->vlan_tci had
- * VLAN_TAG_PRESENT bit and its VID field was 0x000.
+ * At this point, we know that skb->vlan_tci VID
+ * field was 0.
* We update only VID field and preserve PCP field.
*/
skb->vlan_tci |= pvid;
--
2.19.1
^ permalink raw reply related
* [PATCH net-next 4/9] 8021q: use __vlan_hwaccel helpers
From: Michał Mirosław @ 2018-11-08 23:18 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Ajit Khaparde, Alexey Kuznetsov, bridge,
Cong Wang, coreteam, Florian Westphal, Hideaki YOSHIFUJI,
Jamal Hadi Salim, Jiri Pirko, Jozsef Kadlecsik, linux-rdma,
Mirko Lindner, netfilter-devel, Nikolay Aleksandrov,
Pablo Neira Ayuso, Roopa Prabhu, Sathya Perla, Somnath Kotur,
Sriharsha Basavapatna <srih
In-Reply-To: <cover.1541718583.git.mirq-linux@rere.qmqm.pl>
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
net/8021q/vlan_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c
index 4f60e86f4b8d..dd39489c829a 100644
--- a/net/8021q/vlan_core.c
+++ b/net/8021q/vlan_core.c
@@ -57,7 +57,7 @@ bool vlan_do_receive(struct sk_buff **skbp)
}
skb->priority = vlan_get_ingress_priority(vlan_dev, skb->vlan_tci);
- skb->vlan_tci = 0;
+ __vlan_hwaccel_clear_tag(skb);
rx_stats = this_cpu_ptr(vlan_dev_priv(vlan_dev)->vlan_pcpu_stats);
--
2.19.1
^ permalink raw reply related
* [PATCH net-next 3/9] net/core: use __vlan_hwaccel helpers
From: Michał Mirosław @ 2018-11-08 23:18 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Jamal Hadi Salim, Cong Wang, Jiri Pirko,
Ajit Khaparde, Alexey Kuznetsov, bridge, coreteam,
Florian Westphal, Hideaki YOSHIFUJI, Jozsef Kadlecsik, linux-rdma,
Mirko Lindner, netfilter-devel, Nikolay Aleksandrov,
Pablo Neira Ayuso, Roopa Prabhu, Sathya Perla, Somnath Kotur,
Sriharsha Basavapatna <srih
In-Reply-To: <cover.1541718583.git.mirq-linux@rere.qmqm.pl>
This removes assumptions about VLAN_TAG_PRESENT bit.
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
net/core/dev.c | 8 +++++---
net/core/skbuff.c | 2 +-
net/sched/act_vlan.c | 2 +-
3 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 0ffcbdd55fa9..bf7e0a471186 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4889,7 +4889,7 @@ static int __netif_receive_skb_core(struct sk_buff *skb, bool pfmemalloc,
* and set skb->priority like in vlan_do_receive()
* For the time being, just ignore Priority Code Point
*/
- skb->vlan_tci = 0;
+ __vlan_hwaccel_clear_tag(skb);
}
type = skb->protocol;
@@ -5386,7 +5386,9 @@ static struct list_head *gro_list_prepare(struct napi_struct *napi,
}
diffs = (unsigned long)p->dev ^ (unsigned long)skb->dev;
- diffs |= p->vlan_tci ^ skb->vlan_tci;
+ diffs |= skb_vlan_tag_present(p) ^ skb_vlan_tag_present(skb);
+ if (skb_vlan_tag_present(p))
+ diffs |= p->vlan_tci ^ skb->vlan_tci;
diffs |= skb_metadata_dst_cmp(p, skb);
diffs |= skb_metadata_differs(p, skb);
if (maclen == ETH_HLEN)
@@ -5652,7 +5654,7 @@ static void napi_reuse_skb(struct napi_struct *napi, struct sk_buff *skb)
__skb_pull(skb, skb_headlen(skb));
/* restore the reserve we had after netdev_alloc_skb_ip_align() */
skb_reserve(skb, NET_SKB_PAD + NET_IP_ALIGN - skb_headroom(skb));
- skb->vlan_tci = 0;
+ __vlan_hwaccel_clear_tag(skb);
skb->dev = napi->dev;
skb->skb_iif = 0;
skb->encapsulation = 0;
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index b4ee5c8b928f..5bb5eb500605 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -5123,7 +5123,7 @@ int skb_vlan_pop(struct sk_buff *skb)
int err;
if (likely(skb_vlan_tag_present(skb))) {
- skb->vlan_tci = 0;
+ __vlan_hwaccel_clear_tag(skb);
} else {
if (unlikely(!eth_type_vlan(skb->protocol)))
return 0;
diff --git a/net/sched/act_vlan.c b/net/sched/act_vlan.c
index ba677d54a7af..93fdaf707313 100644
--- a/net/sched/act_vlan.c
+++ b/net/sched/act_vlan.c
@@ -63,7 +63,7 @@ static int tcf_vlan_act(struct sk_buff *skb, const struct tc_action *a,
/* extract existing tag (and guarantee no hw-accel tag) */
if (skb_vlan_tag_present(skb)) {
tci = skb_vlan_tag_get(skb);
- skb->vlan_tci = 0;
+ __vlan_hwaccel_clear_tag(skb);
} else {
/* in-payload vlan tag, pop it */
err = __skb_vlan_pop(skb, &tci);
--
2.19.1
^ permalink raw reply related
* [PATCH net-next 2/9] nfnetlink/queue: use __vlan_hwaccel helpers
From: Michał Mirosław @ 2018-11-08 23:18 UTC (permalink / raw)
To: netdev
Cc: Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal,
netfilter-devel, coreteam, Ajit Khaparde, Alexey Kuznetsov,
bridge, Cong Wang, David S. Miller, Hideaki YOSHIFUJI,
Jamal Hadi Salim, Jiri Pirko, linux-rdma, Mirko Lindner,
Nikolay Aleksandrov, Roopa Prabhu, Sathya Perla, Somnath Kotur,
Sriharsha Basavapatna <srih
In-Reply-To: <cover.1541718583.git.mirq-linux@rere.qmqm.pl>
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
net/netfilter/nfnetlink_queue.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/nfnetlink_queue.c b/net/netfilter/nfnetlink_queue.c
index 43041f087eb3..1ce30efe6854 100644
--- a/net/netfilter/nfnetlink_queue.c
+++ b/net/netfilter/nfnetlink_queue.c
@@ -1148,8 +1148,9 @@ static int nfqa_parse_bridge(struct nf_queue_entry *entry,
if (!tb[NFQA_VLAN_TCI] || !tb[NFQA_VLAN_PROTO])
return -EINVAL;
- entry->skb->vlan_tci = ntohs(nla_get_be16(tb[NFQA_VLAN_TCI]));
- entry->skb->vlan_proto = nla_get_be16(tb[NFQA_VLAN_PROTO]);
+ __vlan_hwaccel_put_tag(entry->skb,
+ nla_get_be16(tb[NFQA_VLAN_PROTO]),
+ ntohs(nla_get_be16(tb[NFQA_VLAN_TCI])));
}
if (nfqa[NFQA_L2HDR]) {
--
2.19.1
^ permalink raw reply related
* [PATCH net-next 1/9] cxgb4: use __vlan_hwaccel helpers
From: Michał Mirosław @ 2018-11-08 23:18 UTC (permalink / raw)
To: netdev
Cc: Steve Wise, linux-rdma, Ajit Khaparde, Alexey Kuznetsov, bridge,
Cong Wang, coreteam, David S. Miller, Florian Westphal,
Hideaki YOSHIFUJI, Jamal Hadi Salim, Jiri Pirko, Jozsef Kadlecsik,
Mirko Lindner, netfilter-devel, Nikolay Aleksandrov,
Pablo Neira Ayuso, Roopa Prabhu, Sathya Perla, Somnath Kotur
In-Reply-To: <cover.1541718583.git.mirq-linux@rere.qmqm.pl>
Use __vlan_hwaccel_put_tag() to set vlan tag and proto fields.
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
drivers/infiniband/hw/cxgb4/cm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/infiniband/hw/cxgb4/cm.c b/drivers/infiniband/hw/cxgb4/cm.c
index 615413bd3e8d..8ed01e07c463 100644
--- a/drivers/infiniband/hw/cxgb4/cm.c
+++ b/drivers/infiniband/hw/cxgb4/cm.c
@@ -3944,7 +3944,7 @@ static int rx_pkt(struct c4iw_dev *dev, struct sk_buff *skb)
} else {
vlan_eh = (struct vlan_ethhdr *)(req + 1);
iph = (struct iphdr *)(vlan_eh + 1);
- skb->vlan_tci = ntohs(cpl->vlan);
+ __vlan_hwaccel_put_tag(skb, htons(ETH_P_8021Q), ntohs(cpl->vlan));
}
if (iph->version != 0x4)
--
2.19.1
^ permalink raw reply related
* [PATCH net-next 0/9] Use __vlan_hwaccel_*() helpers
From: Michał Mirosław @ 2018-11-08 23:17 UTC (permalink / raw)
To: netdev
Cc: Ajit Khaparde, Alexey Kuznetsov, bridge, Cong Wang, coreteam,
David S. Miller, Florian Westphal, Hideaki YOSHIFUJI,
Jamal Hadi Salim, Jiri Pirko, Jozsef Kadlecsik, linux-rdma,
Mirko Lindner, netfilter-devel, Nikolay Aleksandrov,
Pablo Neira Ayuso, Roopa Prabhu, Sathya Perla, Somnath Kotur,
Sriharsha Basavapatna <srih
This series removes from networking core and driver code an assumption
about how VLAN tag presence is stored in an skb. This will allow to free
up overloading of VLAN.CFI bit to incidate tag's presence.
Michał Mirosław (9):
cxgb4: use __vlan_hwaccel helpers
nfnetlink/queue: use __vlan_hwaccel helpers
net/core: use __vlan_hwaccel helpers
8021q: use __vlan_hwaccel helpers
bridge: use __vlan_hwaccel helpers
ipv4/tunnel: use __vlan_hwaccel helpers
benet: use __vlan_hwaccel helpers
mlx4: use __vlan_hwaccel helpers
sky2: use __vlan_hwaccel helpers
drivers/infiniband/hw/cxgb4/cm.c | 2 +-
drivers/net/ethernet/emulex/benet/be_main.c | 13 +++++++++----
drivers/net/ethernet/marvell/sky2.c | 6 ++----
drivers/net/ethernet/mellanox/mlx4/en_rx.c | 2 +-
net/8021q/vlan_core.c | 2 +-
net/bridge/br_netfilter_hooks.c | 15 +++++++++------
net/bridge/br_private.h | 2 +-
net/bridge/br_vlan.c | 6 +++---
net/core/dev.c | 8 +++++---
net/core/skbuff.c | 2 +-
net/ipv4/ip_tunnel_core.c | 2 +-
net/netfilter/nfnetlink_queue.c | 5 +++--
net/sched/act_vlan.c | 2 +-
13 files changed, 38 insertions(+), 29 deletions(-)
--
2.19.1
^ permalink raw reply
* Re: [net-next PATCH v2] net: sched: cls_flower: Classify packets using port ranges
From: David Miller @ 2018-11-08 23:15 UTC (permalink / raw)
To: amritha.nambiar
Cc: netdev, jakub.kicinski, sridhar.samudrala, jhs, xiyou.wangcong,
jiri
In-Reply-To: <154162576240.57813.14471543870620442657.stgit@anamhost.jf.intel.com>
From: Amritha Nambiar <amritha.nambiar@intel.com>
Date: Wed, 07 Nov 2018 13:22:42 -0800
> diff --git a/include/uapi/linux/pkt_cls.h b/include/uapi/linux/pkt_cls.h
> index 401d0c1..b63c3cf 100644
> --- a/include/uapi/linux/pkt_cls.h
> +++ b/include/uapi/linux/pkt_cls.h
> @@ -405,6 +405,11 @@ enum {
> TCA_FLOWER_KEY_UDP_SRC, /* be16 */
> TCA_FLOWER_KEY_UDP_DST, /* be16 */
>
> + TCA_FLOWER_KEY_PORT_SRC_MIN, /* be16 */
> + TCA_FLOWER_KEY_PORT_SRC_MAX, /* be16 */
> + TCA_FLOWER_KEY_PORT_DST_MIN, /* be16 */
> + TCA_FLOWER_KEY_PORT_DST_MAX, /* be16 */
> +
> TCA_FLOWER_FLAGS,
> TCA_FLOWER_KEY_VLAN_ID, /* be16 */
> TCA_FLOWER_KEY_VLAN_PRIO, /* u8 */
> @@ -518,6 +523,8 @@ enum {
I don't think you can do this without breaking UAPI, this changes the
value of TCA_FLOWER_FLAGS and all subsequent values in this
enumeration.
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: phy: use phy_id_mask value zero for exact match
From: Florian Fainelli @ 2018-11-08 23:06 UTC (permalink / raw)
To: Andrew Lunn, Heiner Kallweit; +Cc: David Miller, netdev@vger.kernel.org
In-Reply-To: <20181108205349.GG5259@lunn.ch>
On 11/8/18 12:53 PM, Andrew Lunn wrote:
>>> Maybe we can find a clever way with a macro to specify only the PHY OUI
>>> and compute a suitable mask automatically?
>>>
>> I don't think so. For Realtek each driver is specific even to a model
>> revision (therefore mask 0xffffffff). Same applies to intel-xway.
>> In broadcom.c we have masks 0xfffffff0, so for each model, independent
>> of revision number. There is no general rule.
>> Also we can't simply check for the first-bit-set to derive a mask.
>
> I'm crystal ball gazing, but i think Florian was meaning something like
>
> #define PHY_ID_UNIQUE(_id) \
> .phy_id = _id_; \
> .phy_id_mask = 0xffffffff;
>
> It is the boilerplate setting .phy_id_mask which you don't like. This removes that boilerplate.
Your crystal ball gazing skills are good, that is what I meant, we could
also define another macro which does not match the revision bits, and
that would likely cover everything that is already out there.
--
Florian
^ permalink raw reply
* Re: [PATCH net-next 0/2] net: phy: use phy_id_mask value zero for exact match
From: David Miller @ 2018-11-08 23:05 UTC (permalink / raw)
To: hkallweit1; +Cc: f.fainelli, andrew, netdev
In-Reply-To: <08d52675-f308-4ebb-4ec4-f6c7ac0b6b06@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Wed, 7 Nov 2018 21:52:31 +0100
> A phy_id_mask value zero means every PHYID matches, therefore
> value zero isn't used. So we can safely redefine the semantics
> of value zero to mean "exact match". This allows to avoid some
> boilerplate code in PHY driver configs.
>
> Realtek PHY driver is the first user of this change.
It looks like there will be some changes to this series, so I will
wait for the next version.
^ permalink raw reply
* Re: [PATCH net-next 0/5] net: phy: improve and simplify phylib state machine
From: David Miller @ 2018-11-08 23:04 UTC (permalink / raw)
To: f.fainelli; +Cc: hkallweit1, andrew, netdev
In-Reply-To: <911ca9fa-e994-d3f3-2e8d-6f16631c1757@gmail.com>
From: Florian Fainelli <f.fainelli@gmail.com>
Date: Thu, 8 Nov 2018 15:00:01 -0800
> On 11/8/18 2:58 PM, David Miller wrote:
>> From: Heiner Kallweit <hkallweit1@gmail.com>
>> Date: Wed, 7 Nov 2018 20:41:52 +0100
>>
>>> This patch series is based on two axioms:
>>>
>>> - During autoneg a PHY always reports the link being down
>>>
>>> - Info in clause 22/45 registers doesn't allow to differentiate between
>>> these two states:
>>> 1. Link is physically down
>>> 2. A link partner is connected and PHY is autonegotiating
>>> In both cases "link up" and "aneg finished" bits aren't set.
>>> One consequence is that having separate states PHY_NOLINK and PHY_AN
>>> isn't needed.
>>>
>>> By using these two axioms the state machine can be significantly
>>> simplified.
>>
>> So how are we going to move forward on this?
>>
>> Maybe we can apply this series and just watch carefully for any
>> problems that get reported or are found?
>
> Given Heiner is always responsive and taking care of fixing what might
> be/have broken, no objections with me on that.
Great, I've applied this series to net-next then.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/5] net: phy: improve and simplify phylib state machine
From: Andrew Lunn @ 2018-11-08 23:01 UTC (permalink / raw)
To: Florian Fainelli; +Cc: David Miller, hkallweit1, netdev
In-Reply-To: <911ca9fa-e994-d3f3-2e8d-6f16631c1757@gmail.com>
On Thu, Nov 08, 2018 at 03:00:01PM -0800, Florian Fainelli wrote:
> On 11/8/18 2:58 PM, David Miller wrote:
> > From: Heiner Kallweit <hkallweit1@gmail.com>
> > Date: Wed, 7 Nov 2018 20:41:52 +0100
> >
> >> This patch series is based on two axioms:
> >>
> >> - During autoneg a PHY always reports the link being down
> >>
> >> - Info in clause 22/45 registers doesn't allow to differentiate between
> >> these two states:
> >> 1. Link is physically down
> >> 2. A link partner is connected and PHY is autonegotiating
> >> In both cases "link up" and "aneg finished" bits aren't set.
> >> One consequence is that having separate states PHY_NOLINK and PHY_AN
> >> isn't needed.
> >>
> >> By using these two axioms the state machine can be significantly
> >> simplified.
> >
> > So how are we going to move forward on this?
> >
> > Maybe we can apply this series and just watch carefully for any
> > problems that get reported or are found?
>
> Given Heiner is always responsive and taking care of fixing what might
> be/have broken, no objections with me on that.
Yes, lets try it.
Andrew
^ permalink raw reply
* Re: [PATCH net-next 0/5] net: phy: improve and simplify phylib state machine
From: Florian Fainelli @ 2018-11-08 23:00 UTC (permalink / raw)
To: David Miller, hkallweit1; +Cc: andrew, netdev
In-Reply-To: <20181108.145846.295661679780466934.davem@davemloft.net>
On 11/8/18 2:58 PM, David Miller wrote:
> From: Heiner Kallweit <hkallweit1@gmail.com>
> Date: Wed, 7 Nov 2018 20:41:52 +0100
>
>> This patch series is based on two axioms:
>>
>> - During autoneg a PHY always reports the link being down
>>
>> - Info in clause 22/45 registers doesn't allow to differentiate between
>> these two states:
>> 1. Link is physically down
>> 2. A link partner is connected and PHY is autonegotiating
>> In both cases "link up" and "aneg finished" bits aren't set.
>> One consequence is that having separate states PHY_NOLINK and PHY_AN
>> isn't needed.
>>
>> By using these two axioms the state machine can be significantly
>> simplified.
>
> So how are we going to move forward on this?
>
> Maybe we can apply this series and just watch carefully for any
> problems that get reported or are found?
Given Heiner is always responsive and taking care of fixing what might
be/have broken, no objections with me on that.
--
Florian
^ permalink raw reply
* Re: [PATCH net-next 0/5] net: phy: improve and simplify phylib state machine
From: David Miller @ 2018-11-08 22:58 UTC (permalink / raw)
To: hkallweit1; +Cc: f.fainelli, andrew, netdev
In-Reply-To: <922c223b-7bc0-e0ec-345d-2034b796af91@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Wed, 7 Nov 2018 20:41:52 +0100
> This patch series is based on two axioms:
>
> - During autoneg a PHY always reports the link being down
>
> - Info in clause 22/45 registers doesn't allow to differentiate between
> these two states:
> 1. Link is physically down
> 2. A link partner is connected and PHY is autonegotiating
> In both cases "link up" and "aneg finished" bits aren't set.
> One consequence is that having separate states PHY_NOLINK and PHY_AN
> isn't needed.
>
> By using these two axioms the state machine can be significantly
> simplified.
So how are we going to move forward on this?
Maybe we can apply this series and just watch carefully for any
problems that get reported or are found?
^ permalink raw reply
* Re: [PATCH bpf-next v2 02/13] bpf: btf: Add BTF_KIND_FUNC and BTF_KIND_FUNC_PROTO
From: Edward Cree @ 2018-11-08 22:56 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Martin KaFai Lau, Yonghong Song, Alexei Starovoitov,
Daniel Borkmann, Network Development, Kernel Team
In-Reply-To: <CAADnVQJ8Erh=-3Cx1zEhPartsvNz2f-MX-obYDDqAicOyg4nWg@mail.gmail.com>
On 08/11/18 19:42, Alexei Starovoitov wrote:
> same link let's continue at 1pm PST.
So, one thing we didn't really get onto was maps, and you mentioned that it
wasn't really clear what I was proposing there.
What I have in mind comes in two parts:
1) map type. A new BTF_KIND_MAP with metadata 'key_type', 'value_type'
(both are type_ids referencing other BTF type records), describing the
type "map from key_type to value_type".
2) record in the 'instances' table. This would have a name_off (the
name of the map), a type_id (pointing at a BTF_KIND_MAP in the 'types'
table), and potentially also some indication of what symbol (from
section 'maps') refers to this map. This is pretty much the exact
same metadata that a function in the 'instances' table has, the only
differences being
(a) function's type_id points at a BTF_KIND_FUNC record
(b) function's symbol indication refers from .text section
(c) in future functions may be nested inside other functions, whereas
AIUI a map can't live inside a function. (But a variable, which is
the other thing that would want to go in an 'instances' table, can.)
So the 'instances' table record structure looks like
struct btf_instance {
__u32 type_id; /* Type of object declared. An index into type section */
__u32 name_off; /* Name of object. An offset into string section */
__u32 parent; /* Containing object if any (else 0). An index into instance section */
};
and we extend the BTF header:
struct btf_header {
__u16 magic;
__u8 version;
__u8 flags;
__u32 hdr_len;
/* All offsets are in bytes relative to the end of this header */
__u32 type_off; /* offset of type section */
__u32 type_len; /* length of type section */
__u32 str_off; /* offset of string section */
__u32 str_len; /* length of string section */
__u32 inst_off; /* offset of instance section */
__u32 inst_len; /* length of instance section */
};
Then in the .BTF.ext section, we have both
struct bpf_func_info {
__u32 prog_symbol; /* Index of symbol giving address of subprog */
__u32 inst_id; /* Index into instance section */
}
struct bpf_map_info {
{
__u32 map_symbol; /* Index of symbol creating this map */
__u32 inst_id; /* Index into instance section */
}
(either living in different subsections, or in a single table with
the addition of a kind field, or in a single table relying on the
ultimately referenced type to distinguish funcs from maps).
Note that the name (in btf_instance) of a map or function need not
match the name of the corresponding symbol; we use the .BTF.ext
section to tie together btf_instance IDs and symbol IDs. Then in
the case of functions (subprogs), the prog_symbol can be looked
up in the ELF symbol table to find the address (== insn_offset)
of the subprog, as well as the section containing it (since that
might not be .text). Similarly in the case of maps the BTF info
about the map is connected with the info in the maps section.
Now when the loader has munged this, what it passes to the kernel
might not have map_symbol, but instead map_fd. Instead of
prog_symbol it will have whatever identifies the subprog in the
blob of stuff it feeds to the kernel (so probably insn_offset).
All this would of course require a bit more compiler support than
the current BPF_ANNOTATE_KV_PAIR, since that just causes the
existing BTF machinery to declare a specially constructed struct
type. At the C level you could still have BPF_ANNOTATE_KV_PAIR
and the '____bpf_map_foo' name, but then the compiler would
recognise that and convert it into an instance record by looking
up the name 'foo' in its "maps" section. That way the special
____bpf_map_* handling (which ties map names to symbol names,
also) would be entirely compiler-internal and not 'leak out' into
the definition of the format. Frontends for other languages
which do possess a native map type (e.g. Python dict) might have
other ways of indicating the key/value type of a map at source
level (e.g. PEP 484) and could directly generate the appropriate
BTF_KIND_MAP and bpf_map_info records rather than (as they would
with the current design) having to encode the information as a
struct ____bpf_map_foo type-definition.
While I realise the desire to concentrate on one topic at once, I
think this question of maps should be discussed in tomorrow's
call, since it is when we start having other kinds of instances
besides functions that the advantages of my design become
apparent, unifying the process of 'declaration' of functions,
maps, and (eventually) variables while separating them all from
the process of 'definition' of the types of all three.
Thank you for your continued patience with me.
-Ed
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: phy: replace PHY_HAS_INTERRUPT with a check for config_intr and ack_interrupt
From: Heiner Kallweit @ 2018-11-08 22:40 UTC (permalink / raw)
To: Florian Fainelli, Andrew Lunn, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <96112482-1293-0276-8bcc-44bf1beabd59@gmail.com>
On 08.11.2018 23:33, Florian Fainelli wrote:
> On 11/8/18 1:55 PM, Heiner Kallweit wrote:
>> Flag PHY_HAS_INTERRUPT is used only here for this small check. I think
>> using interrupts isn't possible if a driver defines neither
>> config_intr nor ack_interrupts callback. So we can replace checking
>> flag PHY_HAS_INTERRUPT with checking for these callbacks.
>>
>> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
>> ---
>> drivers/net/phy/phy_device.c | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
>> index d165a2c82..33e51b955 100644
>> --- a/drivers/net/phy/phy_device.c
>> +++ b/drivers/net/phy/phy_device.c
>> @@ -2104,8 +2104,9 @@ static int phy_probe(struct device *dev)
>> /* Disable the interrupt if the PHY doesn't support it
>> * but the interrupt is still a valid one
>> */
>> - if (!(phydrv->flags & PHY_HAS_INTERRUPT) &&
>> - phy_interrupt_is_valid(phydev))
>> + if (!phydrv->config_intr &&
>> + !phydrv->ack_interrupt &&
>> + phy_interrupt_is_valid(phydev))
>> phydev->irq = PHY_POLL;
>
> I would introduce an inline helper function which checks for
> drv->config_intr and config_ack_interrupt, that way if we ever have to
> introduce an additional function in the future, we just update the
> helper to check for that.
>
> Other than that, LGTM
>
OK, will add a helper and remove PHY_HAS_INTERRUPT from all drivers.
^ permalink raw reply
* [PATCH net] net: mvneta: Don't advertise 2.5G modes
From: Maxime Chevallier @ 2018-11-09 8:17 UTC (permalink / raw)
To: davem
Cc: Maxime Chevallier, netdev, linux-kernel, Antoine Tenart,
thomas.petazzoni, gregory.clement, Andrew Lunn, Russell King,
linux-arm-kernel
Using 2.5G speed relies on the SerDes lanes being configured
accordingly. The lanes have to be reconfigured to switch between
1G and 2.5G, and for now only the bootloader does this configuration.
In the case we add a Comphy driver to handle switching the lanes
dynamically, it's better for now to stick with supporting only 1G and
add advertisement for 2.5G once we really are capable of handling both
speeds without problem.
Since the interface mode is initialy taken from the DT, we want to make
sure that adding comphy support won't break boards that don't update
their dtb.
Fixes: da58a931f248 ("net: mvneta: Add support for 2500Mbps SGMII")
Reported-by: Andrew Lunn <andrew@lunn.ch>
Reported-by: Russell King <linux@armlinux.org.uk>
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
drivers/net/ethernet/marvell/mvneta.c | 12 +++---------
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mvneta.c b/drivers/net/ethernet/marvell/mvneta.c
index 5bfd349bf41a..c19ecd153499 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -3343,7 +3343,6 @@ static void mvneta_validate(struct net_device *ndev, unsigned long *supported,
if (state->interface != PHY_INTERFACE_MODE_NA &&
state->interface != PHY_INTERFACE_MODE_QSGMII &&
state->interface != PHY_INTERFACE_MODE_SGMII &&
- state->interface != PHY_INTERFACE_MODE_2500BASEX &&
!phy_interface_mode_is_8023z(state->interface) &&
!phy_interface_mode_is_rgmii(state->interface)) {
bitmap_zero(supported, __ETHTOOL_LINK_MODE_MASK_NBITS);
@@ -3357,14 +3356,9 @@ static void mvneta_validate(struct net_device *ndev, unsigned long *supported,
/* Asymmetric pause is unsupported */
phylink_set(mask, Pause);
- /* We cannot use 1Gbps when using the 2.5G interface. */
- if (state->interface == PHY_INTERFACE_MODE_2500BASEX) {
- phylink_set(mask, 2500baseT_Full);
- phylink_set(mask, 2500baseX_Full);
- } else {
- phylink_set(mask, 1000baseT_Full);
- phylink_set(mask, 1000baseX_Full);
- }
+ /* Half-duplex at speeds higher than 100Mbit is unsupported */
+ phylink_set(mask, 1000baseT_Full);
+ phylink_set(mask, 1000baseX_Full);
if (!phy_interface_mode_is_8023z(state->interface)) {
/* 10M and 100M are only supported in non-802.3z mode */
--
2.11.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox