* [PATCH 1/2] can: sja1000: plx_pci: Add support for Moxa CAN devices
From: Marc Kleine-Budde @ 2016-10-31 20:36 UTC (permalink / raw)
To: netdev
Cc: davem, linux-can, kernel, Lukas Resch, Christoph Zehentner,
Marc Kleine-Budde
In-Reply-To: <20161031203620.14384-1-mkl@pengutronix.de>
From: Lukas Resch <l.resch@incubedit.com>
This patch adds support for Moxa CAN devices.
Signed-off-by: Lukas Resch <l.resch@incubedit.com>
Signed-off-by: Christoph Zehentner <c.zehentner@incubedit.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
---
drivers/net/can/sja1000/plx_pci.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/drivers/net/can/sja1000/plx_pci.c b/drivers/net/can/sja1000/plx_pci.c
index 3eb7430dffbf..f8ff25c8ee2e 100644
--- a/drivers/net/can/sja1000/plx_pci.c
+++ b/drivers/net/can/sja1000/plx_pci.c
@@ -142,6 +142,9 @@ struct plx_pci_card {
#define CTI_PCI_VENDOR_ID 0x12c4
#define CTI_PCI_DEVICE_ID_CRG001 0x0900
+#define MOXA_PCI_VENDOR_ID 0x1393
+#define MOXA_PCI_DEVICE_ID 0x0100
+
static void plx_pci_reset_common(struct pci_dev *pdev);
static void plx9056_pci_reset_common(struct pci_dev *pdev);
static void plx_pci_reset_marathon_pci(struct pci_dev *pdev);
@@ -258,6 +261,14 @@ static struct plx_pci_card_info plx_pci_card_info_elcus = {
/* based on PLX9030 */
};
+static struct plx_pci_card_info plx_pci_card_info_moxa = {
+ "MOXA", 2,
+ PLX_PCI_CAN_CLOCK, PLX_PCI_OCR, PLX_PCI_CDR,
+ {0, 0x00, 0x00}, { {0, 0x00, 0x80}, {1, 0x00, 0x80} },
+ &plx_pci_reset_common
+ /* based on PLX9052 */
+};
+
static const struct pci_device_id plx_pci_tbl[] = {
{
/* Adlink PCI-7841/cPCI-7841 */
@@ -357,6 +368,13 @@ static const struct pci_device_id plx_pci_tbl[] = {
0, 0,
(kernel_ulong_t)&plx_pci_card_info_elcus
},
+ {
+ /* moxa */
+ MOXA_PCI_VENDOR_ID, MOXA_PCI_DEVICE_ID,
+ PCI_ANY_ID, PCI_ANY_ID,
+ 0, 0,
+ (kernel_ulong_t)&plx_pci_card_info_moxa
+ },
{ 0,}
};
MODULE_DEVICE_TABLE(pci, plx_pci_tbl);
--
2.10.1
^ permalink raw reply related
* pull-request: can 2016-10-31
From: Marc Kleine-Budde @ 2016-10-31 20:36 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-can, kernel
Hello David,
this is a pull request of two patches for the upcoming v4.9 release.
The first patch is by Lukas Resch for the sja1000 plx_pci driver that adds
support for Moxa CAN devices. The second patch is by Oliver Hartkopp and fixes
a potential kernel panic in the CAN broadcast manager.
regards,
Marc
---
The following changes since commit 46d0847cdd4a3fc1920e56827b9189b9a105d362:
mlxsw: spectrum: Fix incorrect reuse of MID entries (2016-10-31 15:34:43 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can.git tags/linux-can-fixes-for-4.9-20161031
for you to fetch changes up to deb507f91f1adbf64317ad24ac46c56eeccfb754:
can: bcm: fix warning in bcm_connect/proc_register (2016-10-31 20:48:19 +0100)
----------------------------------------------------------------
linux-can-fixes-for-4.9-20161031
----------------------------------------------------------------
Lukas Resch (1):
can: sja1000: plx_pci: Add support for Moxa CAN devices
Oliver Hartkopp (1):
can: bcm: fix warning in bcm_connect/proc_register
drivers/net/can/sja1000/plx_pci.c | 18 ++++++++++++++++++
net/can/bcm.c | 32 +++++++++++++++++++++++---------
2 files changed, 41 insertions(+), 9 deletions(-)
^ permalink raw reply
* [PATCH v2 net-next] net: set SK_MEM_QUANTUM to 4096
From: Eric Dumazet @ 2016-10-31 20:32 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Neal Cardwell, Yuchung Cheng
In-Reply-To: <1477940320.7065.312.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <edumazet@google.com>
Systems with large pages (64KB pages for example) do not always have
huge quantity of memory.
A big SK_MEM_QUANTUM value leads to fewer interactions with the
global counters (like tcp_memory_allocated) but might trigger
memory pressure much faster, giving suboptimal TCP performance
since windows are lowered to ridiculous values.
Note that sysctl_mem units being in pages and in ABI, we also need
to change sk_prot_mem_limits() accordingly.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
include/net/sock.h | 23 +++++++++++++++++------
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/include/net/sock.h b/include/net/sock.h
index f13ac87a8015cb18c5d3fe5fdcf2d6a0592428f4..d904d1835e06c970fea958c048d927137171477f 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -1162,11 +1162,6 @@ static inline void sk_enter_memory_pressure(struct sock *sk)
sk->sk_prot->enter_memory_pressure(sk);
}
-static inline long sk_prot_mem_limits(const struct sock *sk, int index)
-{
- return sk->sk_prot->sysctl_mem[index];
-}
-
static inline long
sk_memory_allocated(const struct sock *sk)
{
@@ -1281,11 +1276,27 @@ int __sk_mem_schedule(struct sock *sk, int size, int kind);
void __sk_mem_reduce_allocated(struct sock *sk, int amount);
void __sk_mem_reclaim(struct sock *sk, int amount);
-#define SK_MEM_QUANTUM ((int)PAGE_SIZE)
+/* We used to have PAGE_SIZE here, but systems with 64KB pages
+ * do not necessarily have 16x time more memory than 4KB ones.
+ */
+#define SK_MEM_QUANTUM 4096
#define SK_MEM_QUANTUM_SHIFT ilog2(SK_MEM_QUANTUM)
#define SK_MEM_SEND 0
#define SK_MEM_RECV 1
+/* sysctl_mem values are in pages, we convert them in SK_MEM_QUANTUM units */
+static inline long sk_prot_mem_limits(const struct sock *sk, int index)
+{
+ long val = sk->sk_prot->sysctl_mem[index];
+
+#if PAGE_SIZE > SK_MEM_QUANTUM
+ val <<= PAGE_SHIFT - SK_MEM_QUANTUM_SHIFT;
+#elif PAGE_SIZE < SK_MEM_QUANTUM
+ val >>= SK_MEM_QUANTUM_SHIFT - PAGE_SHIFT;
+#endif
+ return val;
+}
+
static inline int sk_mem_pages(int amt)
{
return (amt + SK_MEM_QUANTUM - 1) >> SK_MEM_QUANTUM_SHIFT;
^ permalink raw reply related
* Re: [PATCHv2 net] sctp: return back transport in __sctp_rcv_init_lookup
From: David Miller @ 2016-10-31 20:30 UTC (permalink / raw)
To: marcelo.leitner; +Cc: lucien.xin, netdev, linux-sctp, vyasevich, nhorman
In-Reply-To: <20161031201302.GB8514@localhost.localdomain>
From: marcelo.leitner@gmail.com
Date: Mon, 31 Oct 2016 18:13:02 -0200
> On Mon, Oct 31, 2016 at 03:53:48PM -0400, David Miller wrote:
>> From: Xin Long <lucien.xin@gmail.com>
>> Date: Mon, 31 Oct 2016 00:42:35 +0800
>>
>> > Prior to this patch, it used a local variable to save the transport that is
>> > looked up by __sctp_lookup_association(), and didn't return it back. But in
>> > sctp_rcv, it is used to initialize chunk->transport. So when hitting this,
>> > even if it found the transport, it was still initializing chunk->transport
>> > with null instead.
>> >
>> > This patch is to return the transport back through transport pointer
>> > that is from __sctp_rcv_lookup_harder().
>> >
>> > Signed-off-by: Xin Long <lucien.xin@gmail.com>
>>
>> So do I apply this to 'net'? If so I'd like to see explicit ACKs.
>>
>> Thanks.
>
> No. Xin reposted the patchset with this patch updated instead, so please
> ignore this one. Thanks.
>
> Patchset named: [PATCHv2 net 0/3] sctp: a bunch of fixes by holding transport
I got this now, thanks.
^ permalink raw reply
* Re: [PATCH net-next] genetlink: fix error return code in genl_register_family()
From: David Miller @ 2016-10-31 20:29 UTC (permalink / raw)
To: weiyj.lk
Cc: stephen, matti.vaittinen, tom, johannes.berg, pshelar,
tycho.andersen, fw, weiyongjun1, netdev
In-Reply-To: <1477925583-7956-1-git-send-email-weiyj.lk@gmail.com>
From: Wei Yongjun <weiyj.lk@gmail.com>
Date: Mon, 31 Oct 2016 14:53:03 +0000
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Fix to return error code -ENOMEM from the idr_alloc() error handling
> case instead of 0, as done elsewhere in this function.
>
> Fixes: 2ae0f17df1cd ("genetlink: use idr to track families")
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
...
> @@ -362,8 +362,10 @@ int genl_register_family(struct genl_family *family)
>
> family->id = idr_alloc(&genl_fam_idr, family,
> start, end + 1, GFP_KERNEL);
> - if (!family->id)
> + if (!family->id) {
> + err = -ENOMEM;
> goto errout_locked;
> + }
>
> err = genl_validate_assign_mc_groups(family);
> if (err)
idr_alloc() returns negative error codes, not zero, on failure.
So we should return whatever idr_alloc() returns because it has
at least two error return cases (ENOSPC and ENOMEM).
^ permalink raw reply
* Re: XDP question - how much can BPF change in xdp_buff?
From: Tom Herbert @ 2016-10-31 20:29 UTC (permalink / raw)
To: Mintz, Yuval; +Cc: netdev
In-Reply-To: <BY2PR07MB23090DE460B0AE6AA23CD7368DAE0@BY2PR07MB2309.namprd07.prod.outlook.com>
On Mon, Oct 31, 2016 at 11:31 AM, Mintz, Yuval <Yuval.Mintz@cavium.com> wrote:
> So I've [finally] started looking into implementing XDP
> for qede, and there's one thing I feel like I'm missing in
> regard to XDP_TX - what's the guarantee/requirement
> that the bpf program isn't going to transmute some fields
> of the rx packet in a way that would prevent the forwarding?
>
I think there are really two separate questions you're probably
asking. 1) Can XDP modify a packet in such a way that it won't be
forwarded by the driver when XDP_TX is returned, ie. driver would drop
packet 2) Does anything prevent the BPF program from modifying the
packet such that it becomes malformed (bad checksum, mangled headers,
etc.).
I believe the answer to #1 is "no", the XDP interface assumes raw
packets. If program returns XDP_TX then the driver will forward the
raw packet without any further consideration.
The answer to #2 is "no", there is no check that packet produced is
sensible. We assume that the user setting the XDP program knows what
they are doing.
> E.g., can a BPF change the TCP payload of an incoming packet
> without correcting its TCP checksum, and then expect the
> driver to transmit it [via XDP_TX]? If not, how is this enforced [if at all]?
>
It's not enforced. If program doesn't update a checksum then we assume
that forwarded packet is dropped at the receiver.
> [Looked at samples/bpf/xdp2_kern.c which manipulates the
> UDP header; so I'm not certain what prevents it from doing
> the same when checksum modifications would be required]
>
>
>
^ permalink raw reply
* [PATCH net-next 0/2] qed*: Fixes to "Allow unicast filtering"
From: Yuval Mintz @ 2016-10-31 20:26 UTC (permalink / raw)
To: davem, netdev; +Cc: Yuval Mintz
Commit 7b7e70f979e3 ("qed*: Allow unicast filtering") introduced several
issues in driver. This series is intended to address and fix those.
Dave,
These are fixes but I believe the original commit hasn't reached net yet.
So please consider applying these to `net-next'.
Thanks,
Yuval
Yuval Mintz (2):
qede: Don't override priv_flags
qed: Correct VF mac number
drivers/net/ethernet/qlogic/qed/qed_l2.c | 2 ++
drivers/net/ethernet/qlogic/qed/qed_vf.c | 7 +++++++
drivers/net/ethernet/qlogic/qed/qed_vf.h | 13 +++++++++++++
drivers/net/ethernet/qlogic/qede/qede_main.c | 2 +-
4 files changed, 23 insertions(+), 1 deletion(-)
--
1.9.3
^ permalink raw reply
* [PATCH net-next 2/2] qed: Correct VF mac number
From: Yuval Mintz @ 2016-10-31 20:26 UTC (permalink / raw)
To: davem, netdev; +Cc: Yuval Mintz
In-Reply-To: <1477945614-29133-1-git-send-email-Yuval.Mintz@cavium.com>
When relaxing the limitation on the number of unicast MAC filters
an interface can configure, qed started passing the MAC quota to
qede. However, the value is initialized only for PFs, causing VFs
to always try and configure themselves as promiscuous
[as they believe they lack the resources to configure the rx-mode].
Fixes: 7b7e70f979e3 ("qed*: Allow unicast filtering")
Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com>
---
drivers/net/ethernet/qlogic/qed/qed_l2.c | 2 ++
drivers/net/ethernet/qlogic/qed/qed_vf.c | 7 +++++++
drivers/net/ethernet/qlogic/qed/qed_vf.h | 13 +++++++++++++
3 files changed, 22 insertions(+)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_l2.c b/drivers/net/ethernet/qlogic/qed/qed_l2.c
index 1e3a16e..900b253 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_l2.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_l2.c
@@ -1692,6 +1692,8 @@ static int qed_fill_eth_dev_info(struct qed_dev *cdev,
qed_vf_get_num_vlan_filters(&cdev->hwfns[0],
(u8 *)&info->num_vlan_filters);
+ qed_vf_get_num_mac_filters(&cdev->hwfns[0],
+ (u8 *)&info->num_mac_filters);
qed_vf_get_port_mac(&cdev->hwfns[0], info->port_mac);
info->is_legacy = !!cdev->hwfns[0].vf_iov_info->b_pre_fp_hsi;
diff --git a/drivers/net/ethernet/qlogic/qed/qed_vf.c b/drivers/net/ethernet/qlogic/qed/qed_vf.c
index f580bf4..3c06336 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_vf.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_vf.c
@@ -1171,6 +1171,13 @@ void qed_vf_get_num_vlan_filters(struct qed_hwfn *p_hwfn, u8 *num_vlan_filters)
*num_vlan_filters = p_vf->acquire_resp.resc.num_vlan_filters;
}
+void qed_vf_get_num_mac_filters(struct qed_hwfn *p_hwfn, u8 *num_mac_filters)
+{
+ struct qed_vf_iov *p_vf = p_hwfn->vf_iov_info;
+
+ *num_mac_filters = p_vf->acquire_resp.resc.num_mac_filters;
+}
+
bool qed_vf_check_mac(struct qed_hwfn *p_hwfn, u8 *mac)
{
struct qed_bulletin_content *bulletin;
diff --git a/drivers/net/ethernet/qlogic/qed/qed_vf.h b/drivers/net/ethernet/qlogic/qed/qed_vf.h
index 944745b..325c250 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_vf.h
+++ b/drivers/net/ethernet/qlogic/qed/qed_vf.h
@@ -623,6 +623,14 @@ void qed_vf_get_num_vlan_filters(struct qed_hwfn *p_hwfn,
u8 *num_vlan_filters);
/**
+ * @brief Get number of MAC filters allocated for VF by qed
+ *
+ * @param p_hwfn
+ * @param num_rxqs - allocated MAC filters
+ */
+void qed_vf_get_num_mac_filters(struct qed_hwfn *p_hwfn, u8 *num_mac_filters);
+
+/**
* @brief Check if VF can set a MAC address
*
* @param p_hwfn
@@ -872,6 +880,11 @@ static inline void qed_vf_get_num_vlan_filters(struct qed_hwfn *p_hwfn,
{
}
+static inline void qed_vf_get_num_mac_filters(struct qed_hwfn *p_hwfn,
+ u8 *num_mac_filters)
+{
+}
+
static inline bool qed_vf_check_mac(struct qed_hwfn *p_hwfn, u8 *mac)
{
return false;
--
1.9.3
^ permalink raw reply related
* [PATCH net-next 1/2] qede: Don't override priv_flags
From: Yuval Mintz @ 2016-10-31 20:26 UTC (permalink / raw)
To: davem, netdev; +Cc: Yuval Mintz
In-Reply-To: <1477945614-29133-1-git-send-email-Yuval.Mintz@cavium.com>
Driver is now setting the ndev's priv_flags instead of adding to it,
causing pktgen failure to utilize various features due to the loss
of the IFF_TX_SKB_SHARING indication.
Fixes: 7b7e70f979e3 ("qed*: Allow unicast filtering")
Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com>
---
drivers/net/ethernet/qlogic/qede/qede_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/qlogic/qede/qede_main.c b/drivers/net/ethernet/qlogic/qede/qede_main.c
index 873f2eb..df02c45 100644
--- a/drivers/net/ethernet/qlogic/qede/qede_main.c
+++ b/drivers/net/ethernet/qlogic/qede/qede_main.c
@@ -2366,7 +2366,7 @@ static void qede_init_ndev(struct qede_dev *edev)
qede_set_ethtool_ops(ndev);
- ndev->priv_flags = IFF_UNICAST_FLT;
+ ndev->priv_flags |= IFF_UNICAST_FLT;
/* user-changeble features */
hw_features = NETIF_F_GRO | NETIF_F_SG |
--
1.9.3
^ permalink raw reply related
* Re: [PATCH net-next 0/4] bridge: add support for PIM hello router ports
From: David Miller @ 2016-10-31 20:18 UTC (permalink / raw)
To: nikolay; +Cc: netdev, roopa, dwalton, stephen
In-Reply-To: <1477916465-20406-1-git-send-email-nikolay@cumulusnetworks.com>
From: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
Date: Mon, 31 Oct 2016 13:21:01 +0100
> The first 3 patches of this set do minor cleanups and add some helpers to
> the PIM header file. Patch 4 adds a way to detect mcast router ports via
> PIM hello messages, they're marked as temporary and are not considered for
> querier. There's more detailed information in patch 4's commit message.
Looks pretty straight-forward and reasonable, series applied, thanks
Nikolay.
^ permalink raw reply
* Re: [PATCHv2 net 3/3] sctp: hold transport instead of assoc when lookup assoc in rx path
From: Marcelo Ricardo Leitner @ 2016-10-31 20:15 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, linux-sctp, davem, Vlad Yasevich, Neil Horman
In-Reply-To: <c9aed45c28a86d9983447c856f912416fb801426.1477916928.git.lucien.xin@gmail.com>
On Mon, Oct 31, 2016 at 08:32:33PM +0800, Xin Long wrote:
> Prior to this patch, in rx path, before calling lock_sock, it needed to
> hold assoc when got it by __sctp_lookup_association, in case other place
> would free/put assoc.
>
> But in __sctp_lookup_association, it lookup and hold transport, then got
> assoc by transport->assoc, then hold assoc and put transport. It means
> it didn't hold transport, yet it was returned and later on directly
> assigned to chunk->transport.
>
> Without the protection of sock lock, the transport may be freed/put by
> other places, which would cause a use-after-free issue.
>
> This patch is to fix this issue by holding transport instead of assoc.
> As holding transport can make sure to access assoc is also safe, and
> actually it looks up assoc by searching transport rhashtable, to hold
> transport here makes more sense.
>
> Note that the function will be renamed later on on another patch.
>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Thanks
> ---
> include/net/sctp/sctp.h | 2 +-
> net/sctp/input.c | 32 ++++++++++++++++----------------
> net/sctp/ipv6.c | 2 +-
> 3 files changed, 18 insertions(+), 18 deletions(-)
>
> diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
> index 87a7f42..31acc3f 100644
> --- a/include/net/sctp/sctp.h
> +++ b/include/net/sctp/sctp.h
> @@ -152,7 +152,7 @@ void sctp_unhash_endpoint(struct sctp_endpoint *);
> struct sock *sctp_err_lookup(struct net *net, int family, struct sk_buff *,
> struct sctphdr *, struct sctp_association **,
> struct sctp_transport **);
> -void sctp_err_finish(struct sock *, struct sctp_association *);
> +void sctp_err_finish(struct sock *, struct sctp_transport *);
> void sctp_icmp_frag_needed(struct sock *, struct sctp_association *,
> struct sctp_transport *t, __u32 pmtu);
> void sctp_icmp_redirect(struct sock *, struct sctp_transport *,
> diff --git a/net/sctp/input.c b/net/sctp/input.c
> index 8e0bc58..a01a56e 100644
> --- a/net/sctp/input.c
> +++ b/net/sctp/input.c
> @@ -181,9 +181,10 @@ int sctp_rcv(struct sk_buff *skb)
> * bound to another interface, via SO_BINDTODEVICE, treat it as OOTB
> */
> if (sk->sk_bound_dev_if && (sk->sk_bound_dev_if != af->skb_iif(skb))) {
> - if (asoc) {
> - sctp_association_put(asoc);
> + if (transport) {
> + sctp_transport_put(transport);
> asoc = NULL;
> + transport = NULL;
> } else {
> sctp_endpoint_put(ep);
> ep = NULL;
> @@ -269,8 +270,8 @@ int sctp_rcv(struct sk_buff *skb)
> bh_unlock_sock(sk);
>
> /* Release the asoc/ep ref we took in the lookup calls. */
> - if (asoc)
> - sctp_association_put(asoc);
> + if (transport)
> + sctp_transport_put(transport);
> else
> sctp_endpoint_put(ep);
>
> @@ -283,8 +284,8 @@ int sctp_rcv(struct sk_buff *skb)
>
> discard_release:
> /* Release the asoc/ep ref we took in the lookup calls. */
> - if (asoc)
> - sctp_association_put(asoc);
> + if (transport)
> + sctp_transport_put(transport);
> else
> sctp_endpoint_put(ep);
>
> @@ -300,6 +301,7 @@ int sctp_backlog_rcv(struct sock *sk, struct sk_buff *skb)
> {
> struct sctp_chunk *chunk = SCTP_INPUT_CB(skb)->chunk;
> struct sctp_inq *inqueue = &chunk->rcvr->inqueue;
> + struct sctp_transport *t = chunk->transport;
> struct sctp_ep_common *rcvr = NULL;
> int backloged = 0;
>
> @@ -351,7 +353,7 @@ int sctp_backlog_rcv(struct sock *sk, struct sk_buff *skb)
> done:
> /* Release the refs we took in sctp_add_backlog */
> if (SCTP_EP_TYPE_ASSOCIATION == rcvr->type)
> - sctp_association_put(sctp_assoc(rcvr));
> + sctp_transport_put(t);
> else if (SCTP_EP_TYPE_SOCKET == rcvr->type)
> sctp_endpoint_put(sctp_ep(rcvr));
> else
> @@ -363,6 +365,7 @@ int sctp_backlog_rcv(struct sock *sk, struct sk_buff *skb)
> static int sctp_add_backlog(struct sock *sk, struct sk_buff *skb)
> {
> struct sctp_chunk *chunk = SCTP_INPUT_CB(skb)->chunk;
> + struct sctp_transport *t = chunk->transport;
> struct sctp_ep_common *rcvr = chunk->rcvr;
> int ret;
>
> @@ -373,7 +376,7 @@ static int sctp_add_backlog(struct sock *sk, struct sk_buff *skb)
> * from us
> */
> if (SCTP_EP_TYPE_ASSOCIATION == rcvr->type)
> - sctp_association_hold(sctp_assoc(rcvr));
> + sctp_transport_hold(t);
> else if (SCTP_EP_TYPE_SOCKET == rcvr->type)
> sctp_endpoint_hold(sctp_ep(rcvr));
> else
> @@ -537,15 +540,15 @@ struct sock *sctp_err_lookup(struct net *net, int family, struct sk_buff *skb,
> return sk;
>
> out:
> - sctp_association_put(asoc);
> + sctp_transport_put(transport);
> return NULL;
> }
>
> /* Common cleanup code for icmp/icmpv6 error handler. */
> -void sctp_err_finish(struct sock *sk, struct sctp_association *asoc)
> +void sctp_err_finish(struct sock *sk, struct sctp_transport *t)
> {
> bh_unlock_sock(sk);
> - sctp_association_put(asoc);
> + sctp_transport_put(t);
> }
>
> /*
> @@ -641,7 +644,7 @@ void sctp_v4_err(struct sk_buff *skb, __u32 info)
> }
>
> out_unlock:
> - sctp_err_finish(sk, asoc);
> + sctp_err_finish(sk, transport);
> }
>
> /*
> @@ -952,11 +955,8 @@ static struct sctp_association *__sctp_lookup_association(
> goto out;
>
> asoc = t->asoc;
> - sctp_association_hold(asoc);
> *pt = t;
>
> - sctp_transport_put(t);
> -
> out:
> return asoc;
> }
> @@ -986,7 +986,7 @@ int sctp_has_association(struct net *net,
> struct sctp_transport *transport;
>
> if ((asoc = sctp_lookup_association(net, laddr, paddr, &transport))) {
> - sctp_association_put(asoc);
> + sctp_transport_put(transport);
> return 1;
> }
>
> diff --git a/net/sctp/ipv6.c b/net/sctp/ipv6.c
> index f473779..176af30 100644
> --- a/net/sctp/ipv6.c
> +++ b/net/sctp/ipv6.c
> @@ -198,7 +198,7 @@ static void sctp_v6_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
> }
>
> out_unlock:
> - sctp_err_finish(sk, asoc);
> + sctp_err_finish(sk, transport);
> out:
> if (likely(idev != NULL))
> in6_dev_put(idev);
> --
> 2.1.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCHv2 net 2/3] sctp: return back transport in __sctp_rcv_init_lookup
From: Marcelo Ricardo Leitner @ 2016-10-31 20:14 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, linux-sctp, davem, Vlad Yasevich, Neil Horman
In-Reply-To: <8d72a86988a2c16c74c45c52dafbf2bbbe9c3b4d.1477916928.git.lucien.xin@gmail.com>
On Mon, Oct 31, 2016 at 08:32:32PM +0800, Xin Long wrote:
> Prior to this patch, it used a local variable to save the transport that is
> looked up by __sctp_lookup_association(), and didn't return it back. But in
> sctp_rcv, it is used to initialize chunk->transport. So when hitting this,
> even if it found the transport, it was still initializing chunk->transport
> with null instead.
>
> This patch is to return the transport back through transport pointer
> that is from __sctp_rcv_lookup_harder().
>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> ---
> net/sctp/input.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/net/sctp/input.c b/net/sctp/input.c
> index a2ea1d1..8e0bc58 100644
> --- a/net/sctp/input.c
> +++ b/net/sctp/input.c
> @@ -1021,7 +1021,6 @@ static struct sctp_association *__sctp_rcv_init_lookup(struct net *net,
> struct sctphdr *sh = sctp_hdr(skb);
> union sctp_params params;
> sctp_init_chunk_t *init;
> - struct sctp_transport *transport;
> struct sctp_af *af;
>
> /*
> @@ -1052,7 +1051,7 @@ static struct sctp_association *__sctp_rcv_init_lookup(struct net *net,
>
> af->from_addr_param(paddr, params.addr, sh->source, 0);
>
> - asoc = __sctp_lookup_association(net, laddr, paddr, &transport);
> + asoc = __sctp_lookup_association(net, laddr, paddr, transportp);
> if (asoc)
> return asoc;
> }
> --
> 2.1.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCHv2 net 1/3] sctp: hold transport instead of assoc in sctp_diag
From: Marcelo Ricardo Leitner @ 2016-10-31 20:14 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, linux-sctp, davem, Vlad Yasevich, Neil Horman
In-Reply-To: <a58ed3a60643e38876a12ed9193e60f7b38cba4d.1477916928.git.lucien.xin@gmail.com>
On Mon, Oct 31, 2016 at 08:32:31PM +0800, Xin Long wrote:
> In sctp_transport_lookup_process(), Commit 1cceda784980 ("sctp: fix
> the issue sctp_diag uses lock_sock in rcu_read_lock") moved cb() out
> of rcu lock, but it put transport and hold assoc instead, and ignore
> that cb() still uses transport. It may cause a use-after-free issue.
>
> This patch is to hold transport instead of assoc there.
>
> Fixes: 1cceda784980 ("sctp: fix the issue sctp_diag uses lock_sock in rcu_read_lock")
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> ---
> net/sctp/socket.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index 9fbb6fe..71b75f9 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -4480,12 +4480,9 @@ int sctp_transport_lookup_process(int (*cb)(struct sctp_transport *, void *),
> if (!transport || !sctp_transport_hold(transport))
> goto out;
>
> - sctp_association_hold(transport->asoc);
> - sctp_transport_put(transport);
> -
> rcu_read_unlock();
> err = cb(transport, p);
> - sctp_association_put(transport->asoc);
> + sctp_transport_put(transport);
>
> out:
> return err;
> --
> 2.1.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCHv2 net] sctp: return back transport in __sctp_rcv_init_lookup
From: marcelo.leitner @ 2016-10-31 20:13 UTC (permalink / raw)
To: David Miller; +Cc: lucien.xin, netdev, linux-sctp, vyasevich, nhorman
In-Reply-To: <20161031.155348.689672413057243931.davem@davemloft.net>
On Mon, Oct 31, 2016 at 03:53:48PM -0400, David Miller wrote:
> From: Xin Long <lucien.xin@gmail.com>
> Date: Mon, 31 Oct 2016 00:42:35 +0800
>
> > Prior to this patch, it used a local variable to save the transport that is
> > looked up by __sctp_lookup_association(), and didn't return it back. But in
> > sctp_rcv, it is used to initialize chunk->transport. So when hitting this,
> > even if it found the transport, it was still initializing chunk->transport
> > with null instead.
> >
> > This patch is to return the transport back through transport pointer
> > that is from __sctp_rcv_lookup_harder().
> >
> > Signed-off-by: Xin Long <lucien.xin@gmail.com>
>
> So do I apply this to 'net'? If so I'd like to see explicit ACKs.
>
> Thanks.
No. Xin reposted the patchset with this patch updated instead, so please
ignore this one. Thanks.
Patchset named: [PATCHv2 net 0/3] sctp: a bunch of fixes by holding transport
^ permalink raw reply
* [PATCH net] igb: re-assign hw address pointer on reset after PCI error
From: Guilherme G. Piccoli @ 2016-10-31 20:12 UTC (permalink / raw)
To: intel-wired-lan; +Cc: jeffrey.t.kirsher, gpiccoli, netdev
Whenever the igb driver detects the result of a read operation returns
a value composed only by F's (like 0xFFFFFFFF), it will detach the
net_device, clear the hw_addr pointer and warn to the user that adapter's
link is lost - those steps happen on igb_rd32().
In case a PCI error happens on Power architecture, there's a recovery
mechanism called EEH, that will reset the PCI slot and call driver's
handlers to reset the adapter and network functionality as well.
We observed that once hw_addr is NULL after the error is detected on
igb_rd32(), it's never assigned back, so in the process of resetting
the network functionality we got a NULL pointer dereference in both
igb_configure_tx_ring() and igb_configure_rx_ring(). In order to avoid
such bug, we re-assign the hw_addr value in the beginning of the
function igb_reset(), in case the hw_addr is NULL when we reach that
path.
Reported-by: Anthony H. Thai <ahthai@us.ibm.com>
Reported-by: Harsha Thyagaraja <hathyaga@in.ibm.com>
Signed-off-by: Guilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com>
---
drivers/net/ethernet/intel/igb/igb_main.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index edc9a6a..c19119c 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -1873,6 +1873,13 @@ void igb_reset(struct igb_adapter *adapter)
struct e1000_fc_info *fc = &hw->fc;
u32 pba, hwm;
+ /* In case of PCI error, adapter might have lost its HW
+ * address; if we reached this point after an error scenario,
+ * we should re-assign the hw_addr based on the saved io_addr.
+ */
+ if (!hw->hw_addr)
+ hw->hw_addr = adapter->io_addr;
+
/* Repartition Pba for greater than 9k mtu
* To take effect CTRL.RST is required.
*/
--
2.1.0
^ permalink raw reply related
* Re: [PATCH 1/1] xen-netfront: do not cast grant table reference to signed short
From: David Miller @ 2016-10-31 20:06 UTC (permalink / raw)
To: dongli.zhang
Cc: linux-kernel, xen-devel, netdev, boris.ostrovsky, david.vrabel,
jgross
In-Reply-To: <1477892309-7150-1-git-send-email-dongli.zhang@oracle.com>
From: Dongli Zhang <dongli.zhang@oracle.com>
Date: Mon, 31 Oct 2016 13:38:29 +0800
> While grant reference is of type uint32_t, xen-netfront erroneously casts
> it to signed short in BUG_ON().
>
> This would lead to the xen domU panic during boot-up or migration when it
> is attached with lots of paravirtual devices.
>
> Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
Since this is consistent with how the macros in linux/err.h handle "is
this an error" checks, this change looks good to me.
Applied, thanks.
^ permalink raw reply
* Re: [PATCHv2 net] sctp: return back transport in __sctp_rcv_init_lookup
From: David Miller @ 2016-10-31 19:53 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, linux-sctp, marcelo.leitner, vyasevich, nhorman
In-Reply-To: <8d72a86988a2c16c74c45c52dafbf2bbbe9c3b4d.1477845755.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Mon, 31 Oct 2016 00:42:35 +0800
> Prior to this patch, it used a local variable to save the transport that is
> looked up by __sctp_lookup_association(), and didn't return it back. But in
> sctp_rcv, it is used to initialize chunk->transport. So when hitting this,
> even if it found the transport, it was still initializing chunk->transport
> with null instead.
>
> This patch is to return the transport back through transport pointer
> that is from __sctp_rcv_lookup_harder().
>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
So do I apply this to 'net'? If so I'd like to see explicit ACKs.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next v2 0/7] qed*: Patch series
From: David Miller @ 2016-10-31 19:52 UTC (permalink / raw)
To: Yuval.Mintz; +Cc: netdev
In-Reply-To: <1477890867-3789-1-git-send-email-Yuval.Mintz@cavium.com>
From: Yuval Mintz <Yuval.Mintz@cavium.com>
Date: Mon, 31 Oct 2016 07:14:20 +0200
> This series does several things. The bigger changes:
>
> - Add new notification APIs [& Defaults] for various fields.
> The series then utilizes some of those qed <-> qede APIs to bass WoL
> support upon.
>
> - Change the resource allocation scheme to receive the values from
> management firmware, instead of equally sharing resources between
> functions [that might not need those]. That would, e.g., allow us to
> configure additional filters to network interfaces in presence of
> storage [PCI] functions from same adapter.
Series applied, thanks.
^ permalink raw reply
* Re: [net-next PATCH 0/7] stmmac: dwmac-sti refactor+cleanup
From: David Miller @ 2016-10-31 19:47 UTC (permalink / raw)
To: manabian; +Cc: peppe.cavallaro, alexandre.torgue, netdev
In-Reply-To: <20161030200507.851-1-manabian@gmail.com>
From: Joachim Eastwood <manabian@gmail.com>
Date: Sun, 30 Oct 2016 21:05:00 +0100
> This patch set aims to remove the init/exit callbacks from the
> dwmac-sti driver and instead use standard PM callbacks. Doing this
> will also allow us to cleanup the driver.
>
> Eventually the init/exit callbacks will be deprecated and removed
> from all drivers dwmac-* except for dwmac-generic. Drivers will be
> refactored to use standard PM and remove callbacks.
>
> Note that this patch set has only been test compiled and no functional
> change is intended.
I would really like to see some review and testing before applying this
series.
^ permalink raw reply
* Re: pull-request: wireless-drivers-next 2016-10-30
From: David Miller @ 2016-10-31 19:38 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <87insaw5u9.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Sun, 30 Oct 2016 11:20:46 +0200
> few fixes for 4.9. I tagged this on the plane over a slow mosh
> connection while travelling to Plumbers so I might have done something
> wrong, please check more carefully than usually. For example I had to
> redo the signed tag because of some whitespace damage.
>
> Please let me know if there are any problems.
Your subject line says "-next" but clearly these are bug fixes for 'net'
so that's where I pulled this into.
Thanks.
^ permalink raw reply
* Re: [PATCH net] bgmac: stop clearing DMA receive control register right after it is set
From: Hauke Mehrtens @ 2016-10-31 19:32 UTC (permalink / raw)
To: Andy Gospodarek, netdev; +Cc: Rafał Miłecki
In-Reply-To: <1477935123-29638-1-git-send-email-gospo@broadcom.com>
On 10/31/2016 06:32 PM, Andy Gospodarek wrote:
> Current bgmac code initializes some DMA settings in the receive control
> register for some hardware and then immediately clears those settings.
> Not clearing those settings results in ~420Mbps *improvement* in
> throughput; this system can now receive frames at line-rate on Broadcom
> 5871x hardware compared to ~520Mbps today. I also tested a few other
> values but found there to be no discernible difference in CPU
> utilization even if burst size and prefetching values are different.
I think these are the default values from the et driver.
> On the hardware tested there was no need to keep the code that cleared
> all but bits 16-17, but since there is a wide variety of hardware that
> used this driver (I did not look at all hardware docs for hardware using
> this IP block), I find it wise to move this call up and clear bits just
> after reading the default value from the hardware rather than completely
> removing it.
>
> This is a good candidate for -stable >=3.14 since that is when the code
> that was supposed to improve performance (but did not) was introduced.
>
> Signed-off-by: Andy Gospodarek <gospo@broadcom.com>
> Fixes: 56ceecde1f29 ("bgmac: initialize the DMA controller of core...")
> Cc: Hauke Mehrtens <hauke@hauke-m.de>
This patch looks correct.
We used this et driver as a documentation when writing the bgmac driver,
or a specification based on some older version:
https://github.com/RMerl/asuswrt-merlin/blob/master/release/src-rt-7.x.main/src/et/sys/etcgmac.c
This is probably the code used for the dma part:
https://github.com/RMerl/asuswrt-merlin/blob/master/release/src-rt-7.x.main/src/shared/hnddma.c#L1276
Acked-by: Hauke Mehrtens <hauke@hauke-m.de>
> ---
> drivers/net/ethernet/broadcom/bgmac.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/broadcom/bgmac.c b/drivers/net/ethernet/broadcom/bgmac.c
> index 31ca204..91cbf92 100644
> --- a/drivers/net/ethernet/broadcom/bgmac.c
> +++ b/drivers/net/ethernet/broadcom/bgmac.c
> @@ -307,6 +307,10 @@ static void bgmac_dma_rx_enable(struct bgmac *bgmac,
> u32 ctl;
>
> ctl = bgmac_read(bgmac, ring->mmio_base + BGMAC_DMA_RX_CTL);
> +
> + /* preserve ONLY bits 16-17 from current hardware value */
> + ctl &= BGMAC_DMA_RX_ADDREXT_MASK;
> +
> if (bgmac->feature_flags & BGMAC_FEAT_RX_MASK_SETUP) {
> ctl &= ~BGMAC_DMA_RX_BL_MASK;
> ctl |= BGMAC_DMA_RX_BL_128 << BGMAC_DMA_RX_BL_SHIFT;
> @@ -317,7 +321,6 @@ static void bgmac_dma_rx_enable(struct bgmac *bgmac,
> ctl &= ~BGMAC_DMA_RX_PT_MASK;
> ctl |= BGMAC_DMA_RX_PT_1 << BGMAC_DMA_RX_PT_SHIFT;
> }
> - ctl &= BGMAC_DMA_RX_ADDREXT_MASK;
> ctl |= BGMAC_DMA_RX_ENABLE;
> ctl |= BGMAC_DMA_RX_PARITY_DISABLE;
> ctl |= BGMAC_DMA_RX_OVERFLOW_CONT;
>
^ permalink raw reply
* Re: [patch net] mlxsw: spectrum: Fix incorrect reuse of MID entries
From: David Miller @ 2016-10-31 19:36 UTC (permalink / raw)
To: jiri; +Cc: netdev, eladr, idosch, yotamg, nogahf, ogerlitz
In-Reply-To: <1477818562-30185-1-git-send-email-jiri@resnulli.us>
From: Jiri Pirko <jiri@resnulli.us>
Date: Sun, 30 Oct 2016 10:09:22 +0100
> From: Ido Schimmel <idosch@mellanox.com>
>
> In the device, a MID entry represents a group of local ports, which can
> later be bound to a MDB entry.
>
> The lookup of an existing MID entry is currently done using the provided
> MC MAC address and VID, from the Linux bridge. However, this can result
> in an incorrect reuse of the same MID index in different VLAN-unaware
> bridges (same IP MC group and VID 0).
>
> Fix this by performing the lookup based on FID instead of VID, which is
> unique across different bridges.
>
> Fixes: 3a49b4fde2a1 ("mlxsw: Adding layer 2 multicast support")
> Signed-off-by: Ido Schimmel <idosch@mellanox.com>
> Acked-by: Elad Raz <eladr@mellanox.com>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
Applied, should I queue this up for -stable?
^ permalink raw reply
* Re: Let's do P4
From: John Fastabend @ 2016-10-31 19:35 UTC (permalink / raw)
To: Jiri Pirko
Cc: Alexei Starovoitov, Thomas Graf, Jakub Kicinski, netdev, davem,
jhs, roopa, simon.horman, ast, daniel, prem, hannes, jbenc, tom,
mattyk, idosch, eladr, yotamg, nogahf, ogerlitz, linville, andy,
f.fainelli, dsa, vivien.didelot, andrew, ivecera,
Maciej Żenczykowski
In-Reply-To: <20161031171229.GB2895@nanopsycho.orion>
[...]
>>>
>>
>> I think the issue with offloading a P4-AST will be how much work goes
>> into mapping this onto any particular hardware instance. And how much
>> of the P4 language feature set is exposed.
>>
>> For example I suspect MLX switch has a different pipeline than MLX NIC
>> and even different variations of the product lines. The same goes for
>> Intel pipeline in NIC and switch and different products in same line.
>>
>> If P4-ast describes the exact instance of the hardware its an easy task
>> the map is 1:1 but isn't exactly portable. Taking an N table onto a M
>> table pipeline on the other hand is a bit more work and requires various
>> transformations to occur in the runtime API. I'm guessing the class of
>> devices we are talking about here can not reconfigure themselves to
>> match the P4-ast.
>
> I believe we can assume that. the p4ast has to be generic as the
> original p4source is. It would be a terrible mistake to couple it with
> some specific hardware. I only want to use p4ast because it would be easy
> parse in kernel, unlike p4source.
Sure but in the fixed ASIC cases the universe of P4 programs is much
larger than the handful of ones that can be 'accepted' by the device. So
you really need to have some knowledge of the hardware. However if you
believe (guessing from last bullet) that devices will be configurable
in the future then its more likely that the hardware can 'accept' the
program.
>
>
>>
>> In the naive implementation only pipelines that map 1:1 will work. Maybe
>> this is what Alexei is noticing?
>
> P4 is ment to program programable hw, not fixed pipeline.
>
I'm guessing there are no upstream drivers at the moment that support
this though right? The rocker universe bits though could leverage this.
>
>>
>>>
>>>> since I cannot see how one can put the whole p4 language compiler
>>>> into the driver, so this last step of p4ast->hw, I presume, will be
>>>> done by firmware, which will be running full compiler in an embedded cpu
>>>
>>> In case of mlxsw, that compiler would be in driver.
>>>
>>>
>>>> on the switch. To me that's precisely the kernel bypass, since we won't
>>>> have a clue what HW capabilities actually are and won't be able to fine
>>>> grain control them.
>>>> Please correct me if I'm wrong.
>>>
>>> You are wrong. By your definition, everything has to be figured out in
>>> driver and FW does nothing. Otherwise it could do "something else" and
>>> that would be a bypass? Does not make any sense to me whatsoever.
>>>
>>>
>>>>
>>>>> Plus the thing I cannot imagine in the model you propose is table fillup.
>>>>> For ebpf, you use maps. For p4 you would have to have a separate HW-only
>>>>> API. This is very similar to the original John's Flow-API. And therefore
>>>>> a kernel bypass.
>>>>
>>>> I think John's flow api is a better way to expose mellanox switch capabilities.
>>>
>>> We are under impression that p4 suits us nicely. But it is not about
>>> us, it is about finding the common way to do this.
>>>
>>
>> I'll just poke at my FlowAPI question again. For fixed ASICS what is
>> the Flow-API missing. We have a few proof points that show it is both
>> sufficient and usable for the handful of use cases we care about.
>
> Yeah, it is most probably fine. Even for flex ASICs to some point. The
> question is how it stands comparing to other alternatives, like p4
>
Just to be clear the Flow-API _was_ generated from the initial P4 spec.
The header files and tools used with it were autogenerated ("compiled"
in a loose sense) from the P4 program. The piece I never exposed
was the set_* operations to reconfigure running systems. I'm not sure
how valuable this is in practice though.
Also there is a P4-16 spec that will be released shortly that is more
flexible and also more complex.
>
>>
>>>
>>>> I also think it's not fair to call it 'bypass'. I see nothing in it
>>>> that justify such 'swear word' ;)
>>>
>>> John's Flow-API was a kernel bypass. Why? It was a API specifically
>>> designed to directly work with HW tables, without kernel being involved.
>>
>> I don't think that is a fair definition of HW bypass. The SKIP_SW flag
>> does exactly that for 'tc' based offloads and it was not rejected.
>
> No, no, no. You still have possibility to do the same thing in kernel,
> same functionality, with the same API. That is a big difference.
>
>
>>
>> The _real_ reason that seems to have fallen out of this and other
>> discussion is the Flow-API didn't provide an in-kernel translation into
>> an emulated patch. Note we always had a usermode translation to eBPF.
>> A secondary reason appears to be overhead of adding yet another netlink
>> family.
>
> Yeah. Maybe you remember, back then when Flow-API was being discussed,
> I suggested to wrap it under TC as cls_xflows and cls_xflowsaction of
> some sort and do in-kernel datapath implementation. I believe that after
> that, it would be acceptable.
>
As I understand the thread here that is exactly the proposal here right?
With a discussion around if the structures/etc are sufficient or any
alternative representations exist.
>
>>
>>>
>>>
>>>> The goal of flow api was to expose HW features to user space, so that
>>>> user space can program it. For something simple as mellanox switch
>>>> asic it fits perfectly well.
>>>
>>> Again, this is not mlx-asic-specific. And again, that is a kernel bypass.
>>>
>>>
>>>> Unless I misunderstand the bigger goal of this discussion and it's
>>>> about programming ezchip devices.
>>>
>>> No. For network processors, I believe that BPF is nicely offloadable, no
>>> need to do the excercise for that.
>>>
>>>
>>>>
>>>> If the goal is to model hw tcam in the linux kernel then just introduce
>>>> tcam bpf map type. It will be dog slow in user space, but it will
>>>> match exactly what is happnening in the HW and user space can make
>>>> sensible trade-offs.
>>>
>>> No, you got me completely wrong. This is not about the TCAM. This is
>>> about differences in the 2 words (p4/bpf).
>>> Again, for "p4-ish" devices, you have to translate BPF. And as you
>>> noted, it's an instruction set. Very hard if not impossible to parse in
>>> order to get back the original semantics.
>>>
>>
>> I think in this discussion "p4-ish" devices means devices with multiple
>> tables in a pipeline? Not devices that have programmable/configurable
>> pipelines right? And if we get to talking about reconfigurable devices
>> I believe this should be done out of band as it typically means
>> reloading some ucode, etc.
>
> I'm talking about both. But I think we should focus on reconfigurable
> ones, as we probably won't see that much fixed ones in the future.
>
hmm maybe but the 10/40/100Gbps devices are going to be around for some
time. So we need to ensure these work well.
.John
^ permalink raw reply
* Re: [PATCH net] qede: Fix statistics' strings for Tx/Rx queues
From: David Miller @ 2016-10-31 19:34 UTC (permalink / raw)
To: Yuval.Mintz; +Cc: netdev
In-Reply-To: <1477815942-9486-1-git-send-email-Yuval.Mintz@cavium.com>
From: Yuval Mintz <Yuval.Mintz@cavium.com>
Date: Sun, 30 Oct 2016 10:25:42 +0200
> When an interface is configured to use Tx/Rx-only queues,
> the length of the statistics would be shortened to accomodate only the
> statistics required per-each queue, and the values would be provided
> accordingly.
> However, the strings provided would still contain both Tx and Rx strings
> for each one of the queues [regardless of its configuration], which might
> lead to out-of-bound access when filling the buffers as well as incorrect
> statistics presented.
>
> Fixes: 9a4d7e86acf3 ("qede: Add support for Tx/Rx-only queues.")
> Signed-off-by: Yuval Mintz <Yuval.Mintz@cavium.com>
Applied, thanks.
^ permalink raw reply
* [PATCH -next] net: cris: make eth_v10.c explicitly non-modular
From: Paul Gortmaker @ 2016-10-31 19:32 UTC (permalink / raw)
To: netdev
Cc: Paul Gortmaker, David S. Miller, Mikael Starvik, Jesper Nilsson,
linux-cris-kernel
The Makefile/Kconfig currently controlling compilation of this code is:
drivers/net/cris/Makefile:obj-$(CONFIG_ETRAX_ARCH_V10) += eth_v10.o
arch/cris/Kconfig:config ETRAX_ARCH_V10
arch/cris/Kconfig: bool
...meaning that it currently is not being built as a module by anyone.
Lets remove the couple traces of modular infrastructure use, so that
when reading the driver there is no doubt it is builtin-only.
Since module_init translates to device_initcall in the non-modular
case, the init ordering remains unchanged with this commit.
There was a one line wrapper for the int init function, which made no
sense; hence we just put the device_initcall on the true init function
itself and delete the pointless wrapper. In doing that we get rid of
the following compile warning:
WARNING: drivers/net/built-in.o(.text+0x1e28): Section mismatch in
reference from the function etrax_init_module() to the function
.init.text:etrax_ethernet_init()
We don't replace module.h with init.h since the file already has that.
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Mikael Starvik <starvik@axis.com>
Cc: Jesper Nilsson <jesper.nilsson@axis.com>
Cc: netdev@vger.kernel.org
Cc: linux-cris-kernel@axis.com
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
drivers/net/cris/eth_v10.c | 11 +----------
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/net/cris/eth_v10.c b/drivers/net/cris/eth_v10.c
index 221f5f011ff9..b37be25f7459 100644
--- a/drivers/net/cris/eth_v10.c
+++ b/drivers/net/cris/eth_v10.c
@@ -7,9 +7,6 @@
*
*/
-
-#include <linux/module.h>
-
#include <linux/kernel.h>
#include <linux/delay.h>
#include <linux/types.h>
@@ -412,6 +409,7 @@ etrax_ethernet_init(void)
led_next_time = jiffies;
return 0;
}
+device_initcall(etrax_ethernet_init)
/* set MAC address of the interface. called from the core after a
* SIOCSIFADDR ioctl, and from the bootup above.
@@ -1715,11 +1713,6 @@ e100_netpoll(struct net_device* netdev)
}
#endif
-static int
-etrax_init_module(void)
-{
- return etrax_ethernet_init();
-}
static int __init
e100_boot_setup(char* str)
@@ -1742,5 +1735,3 @@ e100_boot_setup(char* str)
}
__setup("etrax100_eth=", e100_boot_setup);
-
-module_init(etrax_init_module);
--
2.8.4
^ 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