* [PATCH net-next V3 04/16] net: fec: pass rxq/txq to fec_enet_rx/tx_queue instead of queue_id
From: Troy Kisky @ 2016-04-06 2:25 UTC (permalink / raw)
To: netdev, davem, fugang.duan, lznuaa
Cc: fabio.estevam, l.stach, andrew, tremyfr, gerg, linux-arm-kernel,
johannes, stillcompiling, sergei.shtylyov, arnd, Troy Kisky
In-Reply-To: <1459909562-22865-1-git-send-email-troy.kisky@boundarydevices.com>
The queue_id is the qid member of struct bufdesc_prop.
Passing rxq/txq will allow the macro FEC_ENET_GET_QUQUE to be removed
in the next patch.
Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
Acked-by: Fugang Duan <fugang.duan@nxp.com>
---
v3:
add Acked-by
combine with "net: fec: pass txq to fec_enet_tx_queue instead of queue_id"
reverted change that passed fep as a parameter
---
drivers/net/ethernet/freescale/fec_main.c | 29 +++++++++++------------------
1 file changed, 11 insertions(+), 18 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 7993040..b4d46f8 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -1156,25 +1156,18 @@ fec_enet_hwtstamp(struct fec_enet_private *fep, unsigned ts,
hwtstamps->hwtstamp = ns_to_ktime(ns);
}
-static void
-fec_enet_tx_queue(struct net_device *ndev, u16 queue_id)
+static void fec_txq(struct net_device *ndev, struct fec_enet_priv_tx_q *txq)
{
- struct fec_enet_private *fep;
+ struct fec_enet_private *fep = netdev_priv(ndev);
struct bufdesc *bdp;
unsigned short status;
struct sk_buff *skb;
- struct fec_enet_priv_tx_q *txq;
struct netdev_queue *nq;
int index = 0;
int entries_free;
- fep = netdev_priv(ndev);
-
- queue_id = FEC_ENET_GET_QUQUE(queue_id);
-
- txq = fep->tx_queue[queue_id];
/* get next bdp of dirty_tx */
- nq = netdev_get_tx_queue(ndev, queue_id);
+ nq = netdev_get_tx_queue(ndev, txq->bd.qid);
bdp = txq->dirty_tx;
/* get next bdp of dirty_tx */
@@ -1268,11 +1261,13 @@ static void
fec_enet_tx(struct net_device *ndev)
{
struct fec_enet_private *fep = netdev_priv(ndev);
+ struct fec_enet_priv_tx_q *txq;
u16 queue_id;
/* First process class A queue, then Class B and Best Effort queue */
for_each_set_bit(queue_id, &fep->work_tx, FEC_ENET_MAX_TX_QS) {
clear_bit(queue_id, &fep->work_tx);
- fec_enet_tx_queue(ndev, queue_id);
+ txq = fep->tx_queue[FEC_ENET_GET_QUQUE(queue_id)];
+ fec_txq(ndev, txq);
}
return;
}
@@ -1328,11 +1323,10 @@ static bool fec_enet_copybreak(struct net_device *ndev, struct sk_buff **skb,
* not been given to the system, we just set the empty indicator,
* effectively tossing the packet.
*/
-static int
-fec_enet_rx_queue(struct net_device *ndev, int budget, u16 queue_id)
+static int fec_rxq(struct net_device *ndev, struct fec_enet_priv_rx_q *rxq,
+ int budget)
{
struct fec_enet_private *fep = netdev_priv(ndev);
- struct fec_enet_priv_rx_q *rxq;
struct bufdesc *bdp;
unsigned short status;
struct sk_buff *skb_new = NULL;
@@ -1350,8 +1344,6 @@ fec_enet_rx_queue(struct net_device *ndev, int budget, u16 queue_id)
#ifdef CONFIG_M532x
flush_cache_all();
#endif
- queue_id = FEC_ENET_GET_QUQUE(queue_id);
- rxq = fep->rx_queue[queue_id];
/* First, grab all of the stats for the incoming packet.
* These get messed up if we get called due to a busy condition.
@@ -1519,11 +1511,12 @@ fec_enet_rx(struct net_device *ndev, int budget)
int pkt_received = 0;
u16 queue_id;
struct fec_enet_private *fep = netdev_priv(ndev);
+ struct fec_enet_priv_rx_q *rxq;
for_each_set_bit(queue_id, &fep->work_rx, FEC_ENET_MAX_RX_QS) {
clear_bit(queue_id, &fep->work_rx);
- pkt_received += fec_enet_rx_queue(ndev,
- budget - pkt_received, queue_id);
+ rxq = fep->rx_queue[FEC_ENET_GET_QUQUE(queue_id)];
+ pkt_received += fec_rxq(ndev, rxq, budget - pkt_received);
}
return pkt_received;
}
--
2.5.0
^ permalink raw reply related
* [PATCH net-next V3 03/16] net: fec: return IRQ_HANDLED if fec_ptp_check_pps_event handled it
From: Troy Kisky @ 2016-04-06 2:25 UTC (permalink / raw)
To: netdev, davem, fugang.duan, lznuaa
Cc: fabio.estevam, l.stach, andrew, tremyfr, gerg, linux-arm-kernel,
johannes, stillcompiling, sergei.shtylyov, arnd, Troy Kisky
In-Reply-To: <1459909562-22865-1-git-send-email-troy.kisky@boundarydevices.com>
fec_ptp_check_pps_event will return 1 if FEC_T_TF_MASK caused
an interrupt. Don't return IRQ_NONE in this case.
Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
---
v3: New patch, came from feedback from another patch.
---
drivers/net/ethernet/freescale/fec_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index a011719..7993040 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -1579,8 +1579,8 @@ fec_enet_interrupt(int irq, void *dev_id)
}
if (fep->ptp_clock)
- fec_ptp_check_pps_event(fep);
-
+ if (fec_ptp_check_pps_event(fep))
+ ret = IRQ_HANDLED;
return ret;
}
--
2.5.0
^ permalink raw reply related
* [PATCH net-next V3 02/16] net: fec: remove unused interrupt FEC_ENET_TS_TIMER
From: Troy Kisky @ 2016-04-06 2:25 UTC (permalink / raw)
To: netdev, davem, fugang.duan, lznuaa
Cc: fabio.estevam, l.stach, andrew, tremyfr, gerg, linux-arm-kernel,
johannes, stillcompiling, sergei.shtylyov, arnd, Troy Kisky
In-Reply-To: <1459909562-22865-1-git-send-email-troy.kisky@boundarydevices.com>
FEC_ENET_TS_TIMER is not checked in the interrupt routine
so there is no need to enable it.
Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
---
v3: New patch
Frank Li said "TS_TIMER should never be triggered."
when discussing another patch.
---
drivers/net/ethernet/freescale/fec.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec.h b/drivers/net/ethernet/freescale/fec.h
index 195122e..6dd0ba8 100644
--- a/drivers/net/ethernet/freescale/fec.h
+++ b/drivers/net/ethernet/freescale/fec.h
@@ -374,8 +374,8 @@ struct bufdesc_ex {
#define FEC_ENET_TS_AVAIL ((uint)0x00010000)
#define FEC_ENET_TS_TIMER ((uint)0x00008000)
-#define FEC_DEFAULT_IMASK (FEC_ENET_TXF | FEC_ENET_RXF | FEC_ENET_MII | FEC_ENET_TS_TIMER)
-#define FEC_NAPI_IMASK (FEC_ENET_MII | FEC_ENET_TS_TIMER)
+#define FEC_DEFAULT_IMASK (FEC_ENET_TXF | FEC_ENET_RXF | FEC_ENET_MII)
+#define FEC_NAPI_IMASK FEC_ENET_MII
#define FEC_RX_DISABLED_IMASK (FEC_DEFAULT_IMASK & (~FEC_ENET_RXF))
/* ENET interrupt coalescing macro define */
--
2.5.0
^ permalink raw reply related
* [PATCH net-next V3 01/16] net: fec: only check queue 0 if RXF_0/TXF_0 interrupt is set
From: Troy Kisky @ 2016-04-06 2:25 UTC (permalink / raw)
To: netdev, davem, fugang.duan, lznuaa
Cc: fabio.estevam, l.stach, andrew, tremyfr, gerg, linux-arm-kernel,
johannes, stillcompiling, sergei.shtylyov, arnd, Troy Kisky
In-Reply-To: <1459909562-22865-1-git-send-email-troy.kisky@boundarydevices.com>
Before queue 0 was always checked if any queue caused an interrupt.
It is better to just mark queue 0 if queue 0 has caused an interrupt.
Signed-off-by: Troy Kisky <troy.kisky@boundarydevices.com>
Acked-by: Fugang Duan <Fugang.duan@nxp.com>
---
v3: add Acked-by
---
drivers/net/ethernet/freescale/fec_main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c
index 08243c2..a011719 100644
--- a/drivers/net/ethernet/freescale/fec_main.c
+++ b/drivers/net/ethernet/freescale/fec_main.c
@@ -1534,14 +1534,14 @@ fec_enet_collect_events(struct fec_enet_private *fep, uint int_events)
if (int_events == 0)
return false;
- if (int_events & FEC_ENET_RXF)
+ if (int_events & FEC_ENET_RXF_0)
fep->work_rx |= (1 << 2);
if (int_events & FEC_ENET_RXF_1)
fep->work_rx |= (1 << 0);
if (int_events & FEC_ENET_RXF_2)
fep->work_rx |= (1 << 1);
- if (int_events & FEC_ENET_TXF)
+ if (int_events & FEC_ENET_TXF_0)
fep->work_tx |= (1 << 2);
if (int_events & FEC_ENET_TXF_1)
fep->work_tx |= (1 << 0);
--
2.5.0
^ permalink raw reply related
* [PATCH net-next V3 00/16] net: fec: cleanup and fixes
From: Troy Kisky @ 2016-04-06 2:25 UTC (permalink / raw)
To: netdev, davem, fugang.duan, lznuaa
Cc: fabio.estevam, l.stach, andrew, tremyfr, gerg, linux-arm-kernel,
johannes, stillcompiling, sergei.shtylyov, arnd, Troy Kisky
V3 has
1 dropped patch "net: fec: print more debug info in fec_timeout"
2 new patches
0002-net-fec-remove-unused-interrupt-FEC_ENET_TS_TIMER.patch
0003-net-fec-return-IRQ_HANDLED-if-fec_ptp_check_pps_even.patch
1 combined patch
0004-net-fec-pass-rxq-txq-to-fec_enet_rx-tx_queue-instead.patch
The changes are noted on individual patches
My measured performance of this series is
before patch set
365 Mbits/sec Tx/407 RX
after patch set
374 Tx/427 Rx
Troy Kisky (16):
net: fec: only check queue 0 if RXF_0/TXF_0 interrupt is set
net: fec: remove unused interrupt FEC_ENET_TS_TIMER
net: fec: return IRQ_HANDLED if fec_ptp_check_pps_event handled it
net: fec: pass rxq/txq to fec_enet_rx/tx_queue instead of queue_id
net: fec: reduce interrupts
net: fec: split off napi routine with 3 queues
net: fec: don't clear all rx queue bits when just one is being checked
net: fec: set cbd_sc without relying on previous value
net: fec: eliminate calls to fec_enet_get_prevdesc
net: fec: move restart test for efficiency
net: fec: clear cbd_sc after transmission to help with debugging
net: fec: dump all tx queues in fec_dump
net: fec: detect tx int lost
net: fec: create subroutine reset_tx_queue
net: fec: call dma_unmap_single on mapped tx buffers at restart
net: fec: don't set cbd_bufaddr unless no mapping error
drivers/net/ethernet/freescale/fec.h | 10 +-
drivers/net/ethernet/freescale/fec_main.c | 410 ++++++++++++++++--------------
2 files changed, 218 insertions(+), 202 deletions(-)
--
2.5.0
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: document missing functions
From: Vivien Didelot @ 2016-04-06 2:02 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev, linux-kernel, kernel, David S. Miller, Florian Fainelli
In-Reply-To: <20160405233943.GA19409@lunn.ch>
Hi Andrew,
Andrew Lunn <andrew@lunn.ch> writes:
> On Tue, Apr 05, 2016 at 11:22:40AM -0400, Vivien Didelot wrote:
>> Add description for the missing port_vlan_prepare, port_fdb_prepare,
>> port_fdb_dump functions in the DSA documentation.
>>
>> Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
>
> Hi Vivien
>
> A few English improvements:
>
>> ---
>> Documentation/networking/dsa/dsa.txt | 16 ++++++++++++++++
>> 1 file changed, 16 insertions(+)
>>
>> diff --git a/Documentation/networking/dsa/dsa.txt b/Documentation/networking/dsa/dsa.txt
>> index 3b196c3..8ba3369 100644
>> --- a/Documentation/networking/dsa/dsa.txt
>> +++ b/Documentation/networking/dsa/dsa.txt
>> @@ -542,6 +542,12 @@ Bridge layer
>> Bridge VLAN filtering
>> ---------------------
>>
>> +- port_vlan_prepare: bridge layer function invoked when the bridge prepares the
>> + configuration of a VLAN on the given port. If the operation is not
>> + programmable, this function should return -EOPNOTSUPP to inform the bridge
>
> s/programmable/supported by the hardware
>
>> + code to fallback to a software implementation. No hardware programmation
>
> s/programmation/setup
>
>> + must be done in this function. See port_vlan_add for this and details.
>> +
>> - port_vlan_add: bridge layer function invoked when a VLAN is configured
>> (tagged or untagged) for the given switch port
>>
>> @@ -552,6 +558,12 @@ Bridge VLAN filtering
>> function that the driver has to call for each VLAN the given port is a member
>> of. A switchdev object is used to carry the VID and bridge flags.
>>
>> +- port_fdb_prepare: bridge layer function invoked when the bridge prepares the
>> + installation of a Forwarding Database entry. If the operation is not
>> + programmable, this function should return -EOPNOTSUPP to inform the bridge
>
> s/programmable/supported
>
>> + code to fallback to a software implementation. No hardware programmation
>
> s/programmation/setup
Done, v2 on its way.
Thanks,
Vivien
^ permalink raw reply
* [PATCH net-next] net: bcmgenet: add BQL support
From: Petri Gynther @ 2016-04-06 0:50 UTC (permalink / raw)
To: netdev; +Cc: davem, f.fainelli, opendmb, jaedon.shin, Petri Gynther
Add Byte Queue Limits (BQL) support to bcmgenet driver.
Signed-off-by: Petri Gynther <pgynther@google.com>
---
drivers/net/ethernet/broadcom/genet/bcmgenet.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
index f7b42b9..9fcd514 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -1221,8 +1221,10 @@ static unsigned int __bcmgenet_tx_reclaim(struct net_device *dev,
dev->stats.tx_packets += pkts_compl;
dev->stats.tx_bytes += bytes_compl;
+ txq = netdev_get_tx_queue(dev, ring->queue);
+ netdev_tx_completed_queue(txq, pkts_compl, bytes_compl);
+
if (ring->free_bds > (MAX_SKB_FRAGS + 1)) {
- txq = netdev_get_tx_queue(dev, ring->queue);
if (netif_tx_queue_stopped(txq))
netif_tx_wake_queue(txq);
}
@@ -1516,6 +1518,8 @@ static netdev_tx_t bcmgenet_xmit(struct sk_buff *skb, struct net_device *dev)
ring->prod_index += nr_frags + 1;
ring->prod_index &= DMA_P_INDEX_MASK;
+ netdev_tx_sent_queue(txq, GENET_CB(skb)->bytes_sent);
+
if (ring->free_bds <= (MAX_SKB_FRAGS + 1))
netif_tx_stop_queue(txq);
@@ -2809,6 +2813,8 @@ static void bcmgenet_hfb_init(struct bcmgenet_priv *priv)
static void bcmgenet_netif_start(struct net_device *dev)
{
struct bcmgenet_priv *priv = netdev_priv(dev);
+ int i;
+ struct netdev_queue *txq;
/* Start the network engine */
bcmgenet_enable_rx_napi(priv);
@@ -2816,6 +2822,14 @@ static void bcmgenet_netif_start(struct net_device *dev)
umac_enable_set(priv, CMD_TX_EN | CMD_RX_EN, true);
+ for (i = 0; i < priv->hw_params->tx_queues; i++) {
+ txq = netdev_get_tx_queue(dev, priv->tx_rings[i].queue);
+ netdev_tx_reset_queue(txq);
+ }
+
+ txq = netdev_get_tx_queue(dev, priv->tx_rings[DESC_INDEX].queue);
+ netdev_tx_reset_queue(txq);
+
netif_tx_start_all_queues(dev);
/* Monitor link interrupts now */
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* Re: [RFC PATCH 5/6] ppp: define reusable device creation functions
From: Stephen Hemminger @ 2016-04-06 0:30 UTC (permalink / raw)
To: Guillaume Nault; +Cc: netdev, linux-ppp, Paul Mackerras, David Miller
In-Reply-To: <20160405211456.GC1305@alphalink.fr>
On Tue, 5 Apr 2016 23:14:56 +0200
Guillaume Nault <g.nault@alphalink.fr> wrote:
> On Tue, Apr 05, 2016 at 08:28:32AM -0700, Stephen Hemminger wrote:
> > On Tue, 5 Apr 2016 02:56:29 +0200
> > Guillaume Nault <g.nault@alphalink.fr> wrote:
> >
> > > Move PPP device initialisation and registration out of
> > > ppp_create_interface().
> > > This prepares code for device registration with rtnetlink.
> > >
> >
> > Does PPP module autoload correctly based on the netlink attributes?
> >
> Patch #6 has MODULE_ALIAS_RTNL_LINK("ppp"). This works fine for
> auto-loading ppp_generic when creating a PPP device with rtnetlink.
> Is there anything else required?
>
That should be enough.
^ permalink raw reply
* 我的信息在:
From: 我的信息在: @ 2016-04-05 23:59 UTC (permalink / raw)
To: netdev
你的老朋友邀你来Q群:343257759
^ permalink raw reply
* Re: [RFC PATCH net 3/4] ipv6: datagram: Update dst cache of a connected datagram sk during pmtu update
From: Martin KaFai Lau @ 2016-04-06 0:11 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev, Eric Dumazet, Wei Wang, Kernel Team
In-Reply-To: <CAM_iQpXV8UrBycmmTn3-FFEoR69OSvc4cWZMGbPnGiHF5aF7Dg@mail.gmail.com>
On Mon, Apr 04, 2016 at 01:45:02PM -0700, Cong Wang wrote:
> I see your point, but calling __ip6_datagram_connect() seems overkill
> here, we don't need to update so many things in the pmtu update context,
> at least IPv4 doesn't do that either. I don't think you have to do that.
>
> So why just updating the dst cache (also some addr cache) here is not
> enough?
I am not sure I understand. I could be missing something.
This patch uses ip6_datagram_dst_update() to do the route lookup and
sk->sk_dst_cache update. ip6_datagram_dst_update() is
created in the first two refactoring patches and is also used by
__ip6_datagram_connect().
Which operations in ip6_datagram_dst_update() could be saved
during the pmtu update?
^ permalink raw reply
* Re: [net PATCH v2 2/2] ipv4/GRO: Make GRO conform to RFC 6864
From: Marcelo Ricardo Leitner @ 2016-04-06 0:04 UTC (permalink / raw)
To: Tom Herbert
Cc: Edward Cree, Herbert Xu, Alexander Duyck, Alexander Duyck,
Jesse Gross, Eric Dumazet, Netdev, David Miller
In-Reply-To: <CALx6S37p7sBZ_=xDpmW90-Aqs2sgnOjcjdvYJhEGZ7Y2=6+gcg@mail.gmail.com>
On Tue, Apr 05, 2016 at 12:36:40PM -0300, Tom Herbert wrote:
> On Tue, Apr 5, 2016 at 12:07 PM, Edward Cree <ecree@solarflare.com> wrote:
> > On 05/04/16 05:32, Herbert Xu wrote:
> >> On Mon, Apr 04, 2016 at 09:26:55PM -0700, Alexander Duyck wrote:
> >>> The question I would have is what are you really losing with increment
> >>> from 0 versus fixed 0? From what I see it is essentially just garbage
> >>> in/garbage out.
> >> GRO is meant to be lossless, that is, you should not be able to
> >> detect its presence from the outside. If you lose information then
> >> you're breaking this rule and people will soon start asking for it
> >> to be disabled in various situations.
> >>
> >> I'm not against doing this per se but it should not be part of the
> >> default configuration.
> > I'm certainly in favour of this being configurable - indeed IMHO it should
> > also be possible to configure GRO with the 'looser' semantics of LRO, so
> > that people who want that can get it without all the horrible "don't confuse
> > Slow Start" hacks, and so that LRO can go away (AIUI the only reasons it
> > exists are (a) improved performance from the 'loose' semantics and (b) old
> > kernels without GRO. We may not be able to kill (b) but we can certainly
> > address (a)).
> >
> > But I don't agree that the default has to be totally lossless; anyone who is
> > caring about the ID fields in atomic datagrams is breaking the RFCs, and can
> > be assumed to Know What They're Doing sufficiently to configure this.
> >
> > On the gripping hand, I feel like GRO+TSO is the wrong model for speeding up
> > forwarding/routing workloads. Instead we should be looking into having lists
> > of SKBs traverse the stack together, splitting the list whenever e.g. the
> > destination changes. That seems like it ought to be much more efficient than
> > rewriting headers twice, once to coalesce a superframe and once to segment it
> > again - and it also means this worry about GRO being lossless can go away.
> > But until someone tries implementing skb batches, we won't know for sure if
> > it works (and I don't have time right now ;)
> >
> Ed,
>
> I thought about that some. It seems like we would want to do both GRO
> and retain all the individual packets in the skb so that we could use
> those for forwarding instead of GSO as I think you're saying. This
Retaining the individual packets would also help to make GRO feasible
for SCTP. SCTP needs to know where each packet ended because of AUTH
chunks and we cannot rely on something like gso_size as each original
packet had it's own size.
I could do it for tx side (see my SCTP/GSO RFC patches) using
skb_gro_receive() with a specially crafted header skb, but I'm not
seeing a way to do it in rx side as I cannot guarantee incoming skbs
will follow that pattern.
Marcelo
> would would work great in the plain forwarding case, but one problem
> is what to do if the host modifies the super packet (for instance when
> forwarding over a tunnel we might add encapsulation header). This
> should work in GSO (although we need to address the limitations around
> 1 encap level), not sure this is easy if we need to add a header to
> each packet in a batch.
>
> Tom
>
>
>
> > -Ed
>
^ permalink raw reply
* Re: [PATCH v3 -next] net/core/dev: Warn on a too-short GRO frame
From: David Miller @ 2016-04-05 23:59 UTC (permalink / raw)
To: aconole; +Cc: netdev, joe, eric.dumazet
In-Reply-To: <1459625203-8637-1-git-send-email-aconole@redhat.com>
From: Aaron Conole <aconole@bytheb.org>
Date: Sat, 2 Apr 2016 15:26:43 -0400
> From: Aaron Conole <aconole@bytheb.org>
>
> When signaling that a GRO frame is ready to be processed, the network stack
> correctly checks length and aborts processing when a frame is less than 14
> bytes. However, such a condition is really indicative of a broken driver,
> and should be loudly signaled, rather than silently dropped as the case is
> today.
>
> Convert the condition to use net_warn_ratelimited() to ensure the stack
> loudly complains about such broken drivers.
>
> Signed-off-by: Aaron Conole <aconole@bytheb.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH v2] net: remove unimplemented RTNH_F_PERVASIVE
From: David Miller @ 2016-04-05 23:57 UTC (permalink / raw)
To: quentin; +Cc: kuznet, jmorris, yoshfuji, kaber, netdev
In-Reply-To: <1459615888-456-1-git-send-email-quentin@armitage.org.uk>
From: Quentin Armitage <quentin@armitage.org.uk>
Date: Sat, 2 Apr 2016 17:51:28 +0100
> Linux 2.1.68 introduced RTNH_F_PERVASIVE, but it had no implementation
> and couldn't be enabled since the required config parameter wasn't in
> any Kconfig file (see commit d088dde7b196 ("ipv4: obsolete config in
> kernel source (IP_ROUTE_PERVASIVE)")).
>
> This commit removes all remaining references to RTNH_F_PERVASIVE.
> Although this will cause userspace applications that were using the
> flag to fail to build, they will be alerted to the fact that using
> RTNH_F_PERVASIVE was not achieving anything.
>
> Signed-off-by: Quentin Armitage <quentin@armitage.org.uk>
Can't really delete values like this from user visible headers. It
can break the build.
What if some library or tool has a table translating RTNH_F_* values
into strings to display to the user? Those sources will stop building
if I apply your changes.
^ permalink raw reply
* Re: [RFC PATCH net 3/4] ipv6: datagram: Update dst cache of a connected datagram sk during pmtu update
From: David Miller @ 2016-04-05 23:56 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: kafai, netdev, edumazet, weiwan, kernel-team
In-Reply-To: <CAM_iQpXV8UrBycmmTn3-FFEoR69OSvc4cWZMGbPnGiHF5aF7Dg@mail.gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Mon, 4 Apr 2016 13:45:02 -0700
> On Sat, Apr 2, 2016 at 7:33 PM, Martin KaFai Lau <kafai@fb.com> wrote:
>> One thing to note is that this patch uses the addresses from the sk
>> instead of iph when updating sk->sk_dst_cache. It is basically the
>> same logic that the __ip6_datagram_connect() is doing, so some
>> refactoring works in the first two patches.
>>
>> AFAIK, a UDP socket can become connected after sending out some
>> datagrams in un-connected state. or It can be connected
>> multiple times to different destinations. I did some quick
>> tests but I could be wrong.
>>
>> I am thinking if there could be a chance that the skb->data, which
>> has the original outgoing iph, is not related to the current
>> connected address. If it is possible, we have to specifically
>> use the addresses in the sk instead of skb->data (i.e. iph) when
>> updating the sk->sk_dst_cache.
>>
>> If we need to use the sk addresses (and other info) to find out a
>> new dst for a connected udp socket, it is better not doing it while
>> the userland is connecting to somewhere else.
>>
>> If the above case is impossible, we can keep using the info from iph to
>> do the dst update for a connected-udp sk without taking the lock.
>
> I see your point, but calling __ip6_datagram_connect() seems overkill
> here, we don't need to update so many things in the pmtu update context,
> at least IPv4 doesn't do that either. I don't think you have to do that.
>
> So why just updating the dst cache (also some addr cache) here is not
> enough?
I think we are steadily getting closer to a version of this fix that
we have some agreement on, right?
Martin can you address Cong's feedback and spin another version of this
series?
Thanks.
^ permalink raw reply
* Re: [net-next PATCH 2/2 v4] ibmvnic: enable RX checksum offload
From: David Miller @ 2016-04-05 23:52 UTC (permalink / raw)
To: tlfalcon; +Cc: netdev, linuxppc-dev, jallen
In-Reply-To: <1459549235-22039-2-git-send-email-tlfalcon@linux.vnet.ibm.com>
From: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
Date: Fri, 1 Apr 2016 17:20:35 -0500
> Enable RX Checksum offload feature in the ibmvnic driver.
>
> Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
Applied.
^ permalink raw reply
* Re: [net-next PATCH 1/2 v4] ibmvnic: map L2/L3/L4 header descriptors to firmware
From: David Miller @ 2016-04-05 23:51 UTC (permalink / raw)
To: tlfalcon; +Cc: netdev, linuxppc-dev, jallen
In-Reply-To: <1459549235-22039-1-git-send-email-tlfalcon@linux.vnet.ibm.com>
From: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
Date: Fri, 1 Apr 2016 17:20:34 -0500
> Allow the VNIC driver to provide descriptors containing
> L2/L3/L4 headers to firmware. This feature is needed
> for greater hardware compatibility and enablement of checksum
> and TCP offloading features.
>
> A new function is included for the hypervisor call,
> H_SEND_SUBCRQ_INDIRECT, allowing a DMA-mapped array of SCRQ
> descriptor elements to be sent to the VNIC server.
>
> These additions will help fully enable checksum offloading as
> well as other features as they are included later.
>
> Signed-off-by: Thomas Falcon <tlfalcon@linux.vnet.ibm.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 2/3] net: dsa: make the FDB add function return void
From: Andrew Lunn @ 2016-04-05 23:51 UTC (permalink / raw)
To: Vivien Didelot
Cc: netdev, linux-kernel, kernel, David S. Miller, Florian Fainelli,
Jiri Pirko, Scott Feldman
In-Reply-To: <1459869875-23815-2-git-send-email-vivien.didelot@savoirfairelinux.com>
On Tue, Apr 05, 2016 at 11:24:34AM -0400, Vivien Didelot wrote:
> The switchdev design implies that a software error should not happen in
> the commit phase since it must have been previously reported in the
> prepare phase. If an hardware error occurs during the commit phase,
> there is nothing switchdev can do about it.
>
> The DSA layer separates port_fdb_prepare and port_fdb_add for simplicity
> and convenience. If an hardware error occurs during the commit phase,
> there is no need to report it outside the DSA driver itself.
>
> Make the DSA port_fdb_add routine return void for explicitness.
>
> Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
> ---
> drivers/net/dsa/bcm_sf2.c | 9 +++++----
> drivers/net/dsa/mv88e6xxx.c | 12 +++++-------
> drivers/net/dsa/mv88e6xxx.h | 6 +++---
> include/net/dsa.h | 2 +-
> net/dsa/slave.c | 16 ++++++++--------
> 5 files changed, 22 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/net/dsa/bcm_sf2.c b/drivers/net/dsa/bcm_sf2.c
> index b847624..feebeaa 100644
> --- a/drivers/net/dsa/bcm_sf2.c
> +++ b/drivers/net/dsa/bcm_sf2.c
> @@ -722,13 +722,14 @@ static int bcm_sf2_sw_fdb_prepare(struct dsa_switch *ds, int port,
> return 0;
> }
>
> -static int bcm_sf2_sw_fdb_add(struct dsa_switch *ds, int port,
> - const struct switchdev_obj_port_fdb *fdb,
> - struct switchdev_trans *trans)
> +static void bcm_sf2_sw_fdb_add(struct dsa_switch *ds, int port,
> + const struct switchdev_obj_port_fdb *fdb,
> + struct switchdev_trans *trans)
> {
> struct bcm_sf2_priv *priv = ds_to_priv(ds);
>
> - return bcm_sf2_arl_op(priv, 0, port, fdb->addr, fdb->vid, true);
> + if (bcm_sf2_arl_op(priv, 0, port, fdb->addr, fdb->vid, true))
> + pr_err("%s: failed to add address\n", __func__);
> }
>
> static int bcm_sf2_sw_fdb_del(struct dsa_switch *ds, int port,
> diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
> index 5a2e46d..bca9a2c 100644
> --- a/drivers/net/dsa/mv88e6xxx.c
> +++ b/drivers/net/dsa/mv88e6xxx.c
> @@ -2090,21 +2090,19 @@ int mv88e6xxx_port_fdb_prepare(struct dsa_switch *ds, int port,
> return 0;
> }
>
> -int mv88e6xxx_port_fdb_add(struct dsa_switch *ds, int port,
> - const struct switchdev_obj_port_fdb *fdb,
> - struct switchdev_trans *trans)
> +void mv88e6xxx_port_fdb_add(struct dsa_switch *ds, int port,
> + const struct switchdev_obj_port_fdb *fdb,
> + struct switchdev_trans *trans)
> {
> int state = is_multicast_ether_addr(fdb->addr) ?
> GLOBAL_ATU_DATA_STATE_MC_STATIC :
> GLOBAL_ATU_DATA_STATE_UC_STATIC;
> struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
> - int ret;
>
> mutex_lock(&ps->smi_mutex);
> - ret = _mv88e6xxx_port_fdb_load(ds, port, fdb->addr, fdb->vid, state);
> + if (_mv88e6xxx_port_fdb_load(ds, port, fdb->addr, fdb->vid, state))
> + netdev_warn(ds->ports[port], "cannot load address\n");
In the SF2 driver you use pr_err, but here netdev_warn. We probably
should be consistent if we error or warn. I would use netdev_error,
since if this fails we probably have a real hardware problem.
Andrew
^ permalink raw reply
* Re: [PATCH] ip6_tunnel: set rtnl_link_ops before calling register_netdevice
From: David Miller @ 2016-04-05 23:49 UTC (permalink / raw)
To: cascardo; +Cc: netdev
In-Reply-To: <1459541870-26938-1-git-send-email-cascardo@redhat.com>
From: Thadeu Lima de Souza Cascardo <cascardo@redhat.com>
Date: Fri, 1 Apr 2016 17:17:50 -0300
> When creating an ip6tnl tunnel with ip tunnel, rtnl_link_ops is not set
> before ip6_tnl_create2 is called. When register_netdevice is called, there
> is no linkinfo attribute in the NEWLINK message because of that.
>
> Setting rtnl_link_ops before calling register_netdevice fixes that.
>
> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@redhat.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net-next 1/3] net: dsa: make the STP state function return void
From: Andrew Lunn @ 2016-04-05 23:47 UTC (permalink / raw)
To: Vivien Didelot
Cc: netdev, linux-kernel, kernel, David S. Miller, Florian Fainelli,
Jiri Pirko, Scott Feldman
In-Reply-To: <1459869875-23815-1-git-send-email-vivien.didelot@savoirfairelinux.com>
> -- port_stp_update: bridge layer function invoked when a given switch port STP
> +- port_stp_state: bridge layer function invoked when a given switch port STP
Hi Vivien
port_stp_state_set might be a better name, to make it clear it is
setting the state, not getting the current state, etc. Most of the
other functions are _add, _prepare, _join, _leave, so _set would fit
the pattern.
Changing to a void makes sense.
Andrew
^ permalink raw reply
* Re: [net PATCH v2 2/2] ipv4/GRO: Make GRO conform to RFC 6864
From: David Miller @ 2016-04-05 23:45 UTC (permalink / raw)
To: ecree; +Cc: herbert, alexander.duyck, aduyck, tom, jesse, edumazet, netdev
In-Reply-To: <5703D4C5.9060305@solarflare.com>
From: Edward Cree <ecree@solarflare.com>
Date: Tue, 5 Apr 2016 16:07:49 +0100
> On the gripping hand, I feel like GRO+TSO is the wrong model for
> speeding up forwarding/routing workloads. Instead we should be
> looking into having lists of SKBs traverse the stack together,
> splitting the list whenever e.g. the destination changes.
"Destination" is a very complicated beast. It's not just a
destination IP address.
It's not even just a full saddr/daddr/TOS triplet.
Packets can be forwarded around based upon any key whatsoever in the
headers. Netfilter can mangle them based upon arbitrary bits in the
packet, as can the packet scheduler classifier actions.
It's therefore not profitable to try this at all, it's completely
pointless unless all the keys match up exactly.
This is why GRO _is_ the proper model to speed this stuff and do
bulk processing, because it still presents a full "packet" to all
of these layers to mangle, rewrite, route, and do whatever else
however they like.
^ permalink raw reply
* Re: [PATCH net-next] net: dsa: document missing functions
From: Andrew Lunn @ 2016-04-05 23:39 UTC (permalink / raw)
To: Vivien Didelot
Cc: netdev, linux-kernel, kernel, David S. Miller, Florian Fainelli
In-Reply-To: <1459869760-23295-1-git-send-email-vivien.didelot@savoirfairelinux.com>
On Tue, Apr 05, 2016 at 11:22:40AM -0400, Vivien Didelot wrote:
> Add description for the missing port_vlan_prepare, port_fdb_prepare,
> port_fdb_dump functions in the DSA documentation.
>
> Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Hi Vivien
A few English improvements:
> ---
> Documentation/networking/dsa/dsa.txt | 16 ++++++++++++++++
> 1 file changed, 16 insertions(+)
>
> diff --git a/Documentation/networking/dsa/dsa.txt b/Documentation/networking/dsa/dsa.txt
> index 3b196c3..8ba3369 100644
> --- a/Documentation/networking/dsa/dsa.txt
> +++ b/Documentation/networking/dsa/dsa.txt
> @@ -542,6 +542,12 @@ Bridge layer
> Bridge VLAN filtering
> ---------------------
>
> +- port_vlan_prepare: bridge layer function invoked when the bridge prepares the
> + configuration of a VLAN on the given port. If the operation is not
> + programmable, this function should return -EOPNOTSUPP to inform the bridge
s/programmable/supported by the hardware
> + code to fallback to a software implementation. No hardware programmation
s/programmation/setup
> + must be done in this function. See port_vlan_add for this and details.
> +
> - port_vlan_add: bridge layer function invoked when a VLAN is configured
> (tagged or untagged) for the given switch port
>
> @@ -552,6 +558,12 @@ Bridge VLAN filtering
> function that the driver has to call for each VLAN the given port is a member
> of. A switchdev object is used to carry the VID and bridge flags.
>
> +- port_fdb_prepare: bridge layer function invoked when the bridge prepares the
> + installation of a Forwarding Database entry. If the operation is not
> + programmable, this function should return -EOPNOTSUPP to inform the bridge
s/programmable/supported
> + code to fallback to a software implementation. No hardware programmation
s/programmation/setup
Andrew
^ permalink raw reply
* Re: [RESEND PATCH net-next v2 0/3] bcmgenet cleanups
From: David Miller @ 2016-04-05 23:34 UTC (permalink / raw)
To: pgynther; +Cc: netdev, f.fainelli, opendmb, jaedon.shin
In-Reply-To: <1459890001-78171-1-git-send-email-pgynther@google.com>
From: Petri Gynther <pgynther@google.com>
Date: Tue, 5 Apr 2016 13:59:58 -0700
> Three cleanup patches for bcmgenet.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH] sctp: Fix error handling for switch statement case in the function sctp_cmd_interprete
From: Bastien Philbert @ 2016-04-05 23:34 UTC (permalink / raw)
To: David Miller, daniel; +Cc: vyasevich, nhorman, linux-sctp, netdev, linux-kernel
In-Reply-To: <20160405.192910.1219063056390496976.davem@davemloft.net>
On 2016-04-05 07:29 PM, David Miller wrote:
> From: Daniel Borkmann <daniel@iogearbox.net>
> Date: Tue, 05 Apr 2016 23:53:52 +0200
>
>> On 04/05/2016 11:36 PM, Bastien Philbert wrote:
>>> This fixes error handling for the switch statement case
>>> SCTP_CMD_SEND_PKT by making the error value of the call
>>> to sctp_packet_transmit equal the variable error due to
>>> this function being able to fail with a error code. In
>>
>> What actual issue have you observed that you fix?
>>
>>> addition allow the call to sctp_ootb_pkt_free afterwards
>>> to free up the no longer in use sctp packet even if the
>>> call to the function sctp_packet_transmit fails in order
>>> to avoid a memory leak here for not freeing the sctp
>>
>> Not sure how this relates to your code?
>
> Bastien, I'm seeing a clear negative pattern with the bug fixes
> you are submitting.
>
> Just now you submitted the ICMP change which obviously was never
> tested because it tried to take the RTNL mutex in atomic context,
> and now this sctp thing.
>
> If you don't start actually testing your changes and expalining
> clearly what the problem actually is, how you discovered it,
> and how you actually tested your patch, I will start completely
> ignoring your patch submissions.
>
Ok sure I will be more careful with my future patches. Sorry about those
two patches :(.
Bastien
^ permalink raw reply
* Re: [net 0/3][pull request] Intel Wired LAN Driver Updates 2016-04-05
From: David Miller @ 2016-04-05 23:32 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, nhorman, sassmann, jogreene, john.ronciak
In-Reply-To: <1459895451-45300-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Tue, 5 Apr 2016 15:30:48 -0700
> This series contains updates to i40e and e1000.
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [PATCH] sctp: Fix error handling for switch statement case in the function sctp_cmd_interprete
From: David Miller @ 2016-04-05 23:29 UTC (permalink / raw)
To: daniel
Cc: bastienphilbert, vyasevich, nhorman, linux-sctp, netdev,
linux-kernel
In-Reply-To: <570433F0.6040506@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Tue, 05 Apr 2016 23:53:52 +0200
> On 04/05/2016 11:36 PM, Bastien Philbert wrote:
>> This fixes error handling for the switch statement case
>> SCTP_CMD_SEND_PKT by making the error value of the call
>> to sctp_packet_transmit equal the variable error due to
>> this function being able to fail with a error code. In
>
> What actual issue have you observed that you fix?
>
>> addition allow the call to sctp_ootb_pkt_free afterwards
>> to free up the no longer in use sctp packet even if the
>> call to the function sctp_packet_transmit fails in order
>> to avoid a memory leak here for not freeing the sctp
>
> Not sure how this relates to your code?
Bastien, I'm seeing a clear negative pattern with the bug fixes
you are submitting.
Just now you submitted the ICMP change which obviously was never
tested because it tried to take the RTNL mutex in atomic context,
and now this sctp thing.
If you don't start actually testing your changes and expalining
clearly what the problem actually is, how you discovered it,
and how you actually tested your patch, I will start completely
ignoring your patch submissions.
^ permalink raw reply
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