* [PATCH net-next 5/7] net: phy: marvell: Refactor m88e1121 RGMII delay configuration
From: Andrew Lunn @ 2017-07-30 20:41 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Florian Fainelli, Andrew Lunn
In-Reply-To: <1501447310-24101-1-git-send-email-andrew@lunn.ch>
Turns out that MII_M1116R_CONTROL_REG_MAC is the same as
MII_88E1121_PHY_MSCR_REG. Refactor the code to set the RGMII delays
into a shared helper.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/phy/marvell.c | 62 +++++++++++++++++++++++++----------------------
1 file changed, 33 insertions(+), 29 deletions(-)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 275647ebaa81..408442bdef0a 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -80,7 +80,7 @@
#define MII_88E1121_PHY_MSCR_REG 21
#define MII_88E1121_PHY_MSCR_RX_DELAY BIT(5)
#define MII_88E1121_PHY_MSCR_TX_DELAY BIT(4)
-#define MII_88E1121_PHY_MSCR_DELAY_MASK (~(0x3 << 4))
+#define MII_88E1121_PHY_MSCR_DELAY_MASK (~(BIT(5) || BIT(4)))
#define MII_88E1121_MISC_TEST 0x1a
#define MII_88E1510_MISC_TEST_TEMP_THRESHOLD_MASK 0x1f00
@@ -127,8 +127,6 @@
#define MII_M1011_PHY_STATUS_RESOLVED 0x0800
#define MII_M1011_PHY_STATUS_LINK 0x0400
-#define MII_M1116R_CONTROL_REG_MAC 21
-
#define MII_88E3016_PHY_SPEC_CTRL 0x10
#define MII_88E3016_DISABLE_SCRAMBLER 0x0200
#define MII_88E3016_AUTO_MDIX_CROSSOVER 0x0030
@@ -442,7 +440,7 @@ static int marvell_of_reg_init(struct phy_device *phydev)
}
#endif /* CONFIG_OF_MDIO */
-static int m88e1121_config_aneg(struct phy_device *phydev)
+static int m88e1121_config_aneg_rgmii_delays(struct phy_device *phydev)
{
int err, oldpage, mscr;
@@ -450,25 +448,40 @@ static int m88e1121_config_aneg(struct phy_device *phydev)
if (oldpage < 0)
return oldpage;
- if (phy_interface_is_rgmii(phydev)) {
- mscr = phy_read(phydev, MII_88E1121_PHY_MSCR_REG) &
- MII_88E1121_PHY_MSCR_DELAY_MASK;
-
- if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID)
- mscr |= (MII_88E1121_PHY_MSCR_RX_DELAY |
- MII_88E1121_PHY_MSCR_TX_DELAY);
- else if (phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID)
- mscr |= MII_88E1121_PHY_MSCR_RX_DELAY;
- else if (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID)
- mscr |= MII_88E1121_PHY_MSCR_TX_DELAY;
-
- err = phy_write(phydev, MII_88E1121_PHY_MSCR_REG, mscr);
- if (err < 0)
- return err;
+ mscr = phy_read(phydev, MII_88E1121_PHY_MSCR_REG);
+ if (mscr < 0) {
+ err = mscr;
+ goto out;
}
+ mscr &= MII_88E1121_PHY_MSCR_DELAY_MASK;
+
+ if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID)
+ mscr |= (MII_88E1121_PHY_MSCR_RX_DELAY |
+ MII_88E1121_PHY_MSCR_TX_DELAY);
+ else if (phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID)
+ mscr |= MII_88E1121_PHY_MSCR_RX_DELAY;
+ else if (phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID)
+ mscr |= MII_88E1121_PHY_MSCR_TX_DELAY;
+
+ err = phy_write(phydev, MII_88E1121_PHY_MSCR_REG, mscr);
+
+out:
marvell_set_page(phydev, oldpage);
+ return err;
+}
+
+static int m88e1121_config_aneg(struct phy_device *phydev)
+{
+ int err = 0;
+
+ if (phy_interface_is_rgmii(phydev)) {
+ err = m88e1121_config_aneg_rgmii_delays(phydev);
+ if (err)
+ return err;
+ }
+
err = genphy_soft_reset(phydev);
if (err < 0)
return err;
@@ -650,16 +663,7 @@ static int m88e1116r_config_init(struct phy_device *phydev)
if (err < 0)
return err;
- err = marvell_set_page(phydev, MII_MARVELL_MSCR_PAGE);
- if (err < 0)
- return err;
- temp = phy_read(phydev, MII_M1116R_CONTROL_REG_MAC);
- temp |= (1 << 5);
- temp |= (1 << 4);
- err = phy_write(phydev, MII_M1116R_CONTROL_REG_MAC, temp);
- if (err < 0)
- return err;
- err = marvell_set_page(phydev, MII_MARVELL_COPPER_PAGE);
+ err = m88e1121_config_aneg_rgmii_delays(phydev);
if (err < 0)
return err;
--
2.13.2
^ permalink raw reply related
* [PATCH net-next 7/7] net: phy: marvell: Refactor setting downshift into a helper
From: Andrew Lunn @ 2017-07-30 20:41 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Florian Fainelli, Andrew Lunn
In-Reply-To: <1501447310-24101-1-git-send-email-andrew@lunn.ch>
The 1116r has code to set downshift. Refactor this into a helper, so
in future other marvell PHYs can use it.
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
---
drivers/net/phy/marvell.c | 24 +++++++++++++++++++-----
1 file changed, 19 insertions(+), 5 deletions(-)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index 34fd15b904e7..361fe9927ef2 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -58,6 +58,7 @@
#define MII_M1011_PHY_SCR 0x10
#define MII_M1011_PHY_SCR_DOWNSHIFT_EN BIT(11)
#define MII_M1011_PHY_SCR_DOWNSHIFT_SHIFT 12
+#define MII_M1011_PHY_SRC_DOWNSHIFT_MASK 0x7800
#define MII_M1011_PHY_SCR_MDI (0x0 << 5)
#define MII_M1011_PHY_SCR_MDI_X (0x1 << 5)
#define MII_M1011_PHY_SCR_AUTO_CROSS (0x3 << 5)
@@ -263,6 +264,23 @@ static int marvell_set_polarity(struct phy_device *phydev, int polarity)
return 0;
}
+static int marvell_set_downshift(struct phy_device *phydev, bool enable,
+ u8 retries)
+{
+ int reg;
+
+ reg = phy_read(phydev, MII_M1011_PHY_SCR);
+ if (reg < 0)
+ return reg;
+
+ reg &= MII_M1011_PHY_SRC_DOWNSHIFT_MASK;
+ reg |= ((retries - 1) << MII_M1011_PHY_SCR_DOWNSHIFT_SHIFT);
+ if (enable)
+ reg |= MII_M1011_PHY_SCR_DOWNSHIFT_EN;
+
+ return phy_write(phydev, MII_M1011_PHY_SCR, reg);
+}
+
static int marvell_config_aneg(struct phy_device *phydev)
{
int err;
@@ -643,7 +661,6 @@ static int marvell_config_init(struct phy_device *phydev)
static int m88e1116r_config_init(struct phy_device *phydev)
{
- int temp;
int err;
err = genphy_soft_reset(phydev);
@@ -660,10 +677,7 @@ static int m88e1116r_config_init(struct phy_device *phydev)
if (err < 0)
return err;
- temp = phy_read(phydev, MII_M1011_PHY_SCR);
- temp |= (7 << MII_M1011_PHY_SCR_DOWNSHIFT_SHIFT);
- temp |= MII_M1011_PHY_SCR_DOWNSHIFT_EN;
- err = phy_write(phydev, MII_M1011_PHY_SCR, temp);
+ err = marvell_set_downshift(phydev, true, 8);
if (err < 0)
return err;
--
2.13.2
^ permalink raw reply related
* Re: Kernel TLS in 4.13-rc1
From: David Oberhollenzer @ 2017-07-30 21:14 UTC (permalink / raw)
To: Dave Watson; +Cc: netdev, Richard Weinberger
In-Reply-To: <20170724211019.GA88539@davejwatson-mba.local>
On 07/24/2017 11:10 PM, Dave Watson wrote:
> On 07/23/17 09:39 PM, David Oberhollenzer wrote:
>> After fixing the benchmark/test tool that the patch description
>> linked to (https://github.com/Mellanox/tls-af_ktls_tool) to make
>> sure that the server and client actually *agree* on AES-128-GCM,
>> I simply ran the client program with the --verify-sendpage option.
>>
>> The handshake and setting up of the sockets appears to work but
>> the program complains that the sent and received page contents
>> do not match (sent is 0x12 repeated all over and received looks
>> pretty random).
>
> The --verify functions depend on the RX path as well, which has not
> been merged. Any programs / tests using OpenSSL + patches should work
> fine.
>
> If you want to use the tool, something like this should work, so that
> the receive path uses gnutls:
>
> ./server --no-echo
>
> ./client --server-port 12345 --sendfile some_file --server-host localhost
>
Thanks! This appears to work as expected (output from the server matches the
input from the client and the pcap dumps look fine).
>From briefly browsing through the code of the test tool I was initially under
the impression that it would generate an error message and terminate if an
attempt was made at configuring ktls for the RX path.
Anyway, I already read in the patch description that RX wasn't included yet,
still requires a few cleanups and would follow at some point.
Is there currently a "not-so-clean" version of the RX patches floating around
somewhere that we could take a look at?
Thanks,
David
^ permalink raw reply
* [PATCH] hyperv: netvsc: Neaten netvsc_send_pkt by using a temporary
From: Joe Perches @ 2017-07-30 21:19 UTC (permalink / raw)
To: K. Y. Srinivasan, Haiyang Zhang, Stephen Hemminger
Cc: devel, netdev, linux-kernel
Repeated dereference of nvmsg.msg.v1_msg.send_rndis_pkt can be
shortened by using a temporary. Do so.
No change in object code.
Signed-off-by: Joe Perches <joe@perches.com>
---
drivers/net/hyperv/netvsc.c | 24 ++++++++++--------------
1 file changed, 10 insertions(+), 14 deletions(-)
diff --git a/drivers/net/hyperv/netvsc.c b/drivers/net/hyperv/netvsc.c
index 06f39a99da7c..fede1546cdc6 100644
--- a/drivers/net/hyperv/netvsc.c
+++ b/drivers/net/hyperv/netvsc.c
@@ -743,6 +743,7 @@ static inline int netvsc_send_pkt(
struct sk_buff *skb)
{
struct nvsp_message nvmsg;
+ struct nvsp_1_message_send_rndis_packet *rpkt;
struct netvsc_channel *nvchan
= &net_device->chan_table[packet->q_idx];
struct vmbus_channel *out_channel = nvchan->channel;
@@ -754,21 +755,17 @@ static inline int netvsc_send_pkt(
u32 ring_avail = hv_ringbuf_avail_percent(&out_channel->outbound);
nvmsg.hdr.msg_type = NVSP_MSG1_TYPE_SEND_RNDIS_PKT;
- if (skb != NULL) {
- /* 0 is RMC_DATA; */
- nvmsg.msg.v1_msg.send_rndis_pkt.channel_type = 0;
- } else {
- /* 1 is RMC_CONTROL; */
- nvmsg.msg.v1_msg.send_rndis_pkt.channel_type = 1;
- }
+ rpkt = &nvmsg.msg.v1_msg.send_rndis_pkt;
+ if (skb != NULL)
+ rpkt->channel_type = 0; /* 0 is RMC_DATA */
+ else
+ rpkt->channel_type = 1; /* 1 is RMC_CONTROL */
- nvmsg.msg.v1_msg.send_rndis_pkt.send_buf_section_index =
- packet->send_buf_index;
+ rpkt->send_buf_section_index = packet->send_buf_index;
if (packet->send_buf_index == NETVSC_INVALID_INDEX)
- nvmsg.msg.v1_msg.send_rndis_pkt.send_buf_section_size = 0;
+ rpkt->send_buf_section_size = 0;
else
- nvmsg.msg.v1_msg.send_rndis_pkt.send_buf_section_size =
- packet->total_data_buflen;
+ rpkt->send_buf_section_size = packet->total_data_buflen;
req_id = (ulong)skb;
@@ -776,8 +773,7 @@ static inline int netvsc_send_pkt(
return -ENODEV;
if (packet->page_buf_cnt) {
- pgbuf = packet->cp_partial ? (*pb) +
- packet->rmsg_pgcnt : (*pb);
+ pgbuf = packet->cp_partial ? *pb + packet->rmsg_pgcnt : *pb;
ret = vmbus_sendpacket_pagebuffer_ctl(out_channel,
pgbuf,
packet->page_buf_cnt,
--
2.10.0.rc2.1.g053435c
^ permalink raw reply related
* Re: Performance regression with virtio_net
From: Euan Kemp @ 2017-07-30 22:25 UTC (permalink / raw)
To: mst, seth.forshee; +Cc: netdev
I've also observed this performance regression.
The minimal fix for me is removing the two
> if (unlikely(len > (unsigned long)ctx))
checks added in 680557c.
After digging a little more, the reason that check can fail appears to
be that add_recvbuf_mergeable sometimes includes a hole at the end,
which is included in len but not ctx.
I'd send a patch removing those conditions, but I'm not certain
whether "truesize" in receive_mergeable should also be changed back to
be the max of len/ctx, or should remain as-is.
- Euan
^ permalink raw reply
* I am Mrs Kivi Kangas, citizen of Finland and 68 years old.
From: Office File @ 2017-07-30 23:36 UTC (permalink / raw)
Dear Beloved One.
I am writing this mail with tears and sorrow seeking your assistance
due to my medical situation here in London. I am Mrs Kivi Kangas,
citizen of Finland and 68 years old. I was an Orphan, adopted by my
late father, Engr. Grain Kangas, Chairman/CEO of Grainkangas Oil and
Gas Services. After the death of my father, I took over his company
management and also decided not to get married since I am his only
Child.
Since then, I started suffering from Coronary heart disease which has
cost me a lot and also affected every part of my body and brain cells
due to complications. Just 5 days ago, the British doctors told me
that I may die any time because my condition has gotten to a critical
and life threatening stage. Having known my medical critical status, I
therefore decided to seek for your urgent assistance/ cooperation to
use my inheritance $18.3 Million USD, to Build Orphanage homes in
memory of me when am gone.
I took this bold decision because I do not have husband, family or
children that can inherit these funds when am gone. If interested, you
shall take 25% out of the total money for your assistance, and also
use the balance to build Orphanage homes in memory of me. I
interested, get back to me urgently for more details and to
proceed.Immediately I hearing from you through this email (
mrskivikangas68@gmail.com ), I shall issue you Certificate of
Deposit and my father death certificate for your confirmation before
we proceed, to establish you as my legal beneficiary in receiving the
money on my behalf.
I am waiting to hearing from you urgently.
Regards,
Mrs Kivi Kangas
^ permalink raw reply
* [PATCH v5 net-next] net: systemport: Support 64bit statistics
From: Jianming.qiao @ 2017-07-31 0:01 UTC (permalink / raw)
To: f.fainelli, davem, netdev
When using Broadcom Systemport device in 32bit Platform, ifconfig can
only report up to 4G tx,rx status, which will be wrapped to 0 when the
number of incoming or outgoing packets exceeds 4G, only taking
around 2 hours in busy network environment (such as streaming).
Therefore, it makes hard for network diagnostic tool to get reliable
statistical result, so the patch is used to add 64bit support for
Broadcom Systemport device in 32bit Platform.
Signed-off-by: Jianming.qiao <kiki-good@hotmail.com>
---
drivers/net/ethernet/broadcom/bcmsysport.c | 68 ++++++++++++++++++++----------
drivers/net/ethernet/broadcom/bcmsysport.h | 9 +++-
2 files changed, 52 insertions(+), 25 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bcmsysport.c b/drivers/net/ethernet/broadcom/bcmsysport.c
index 5333601..c0df4f9 100644
--- a/drivers/net/ethernet/broadcom/bcmsysport.c
+++ b/drivers/net/ethernet/broadcom/bcmsysport.c
@@ -662,6 +662,7 @@ static int bcm_sysport_alloc_rx_bufs(struct bcm_sysport_priv *priv)
static unsigned int bcm_sysport_desc_rx(struct bcm_sysport_priv *priv,
unsigned int budget)
{
+ struct bcm_sysport_stats *stats64 = &priv->stats64;
struct net_device *ndev = priv->netdev;
unsigned int processed = 0, to_process;
struct bcm_sysport_cb *cb;
@@ -765,6 +766,10 @@ static unsigned int bcm_sysport_desc_rx(struct bcm_sysport_priv *priv,
skb->protocol = eth_type_trans(skb, ndev);
ndev->stats.rx_packets++;
ndev->stats.rx_bytes += len;
+ u64_stats_update_begin(&stats64->syncp);
+ stats64->rx_packets++;
+ stats64->rx_bytes += len;
+ u64_stats_update_end(&stats64->syncp);
napi_gro_receive(&priv->napi, skb);
next:
@@ -787,17 +792,15 @@ static void bcm_sysport_tx_reclaim_one(struct bcm_sysport_tx_ring *ring,
struct device *kdev = &priv->pdev->dev;
if (cb->skb) {
- ring->bytes += cb->skb->len;
*bytes_compl += cb->skb->len;
dma_unmap_single(kdev, dma_unmap_addr(cb, dma_addr),
dma_unmap_len(cb, dma_len),
DMA_TO_DEVICE);
- ring->packets++;
(*pkts_compl)++;
bcm_sysport_free_cb(cb);
/* SKB fragment */
} else if (dma_unmap_addr(cb, dma_addr)) {
- ring->bytes += dma_unmap_len(cb, dma_len);
+ *bytes_compl += dma_unmap_len(cb, dma_len);
dma_unmap_page(kdev, dma_unmap_addr(cb, dma_addr),
dma_unmap_len(cb, dma_len), DMA_TO_DEVICE);
dma_unmap_addr_set(cb, dma_addr, 0);
@@ -808,9 +811,10 @@ static void bcm_sysport_tx_reclaim_one(struct bcm_sysport_tx_ring *ring,
static unsigned int __bcm_sysport_tx_reclaim(struct bcm_sysport_priv *priv,
struct bcm_sysport_tx_ring *ring)
{
- struct net_device *ndev = priv->netdev;
unsigned int c_index, last_c_index, last_tx_cn, num_tx_cbs;
+ struct bcm_sysport_stats *stats64 = &priv->stats64;
unsigned int pkts_compl = 0, bytes_compl = 0;
+ struct net_device *ndev = priv->netdev;
struct bcm_sysport_cb *cb;
u32 hw_ind;
@@ -849,6 +853,11 @@ static unsigned int __bcm_sysport_tx_reclaim(struct bcm_sysport_priv *priv,
last_c_index &= (num_tx_cbs - 1);
}
+ u64_stats_update_begin(&stats64->syncp);
+ ring->packets += pkts_compl;
+ ring->bytes += bytes_compl;
+ u64_stats_update_end(&stats64->syncp);
+
ring->c_index = c_index;
netif_dbg(priv, tx_done, ndev,
@@ -1671,24 +1680,6 @@ static int bcm_sysport_change_mac(struct net_device *dev, void *p)
return 0;
}
-static struct net_device_stats *bcm_sysport_get_nstats(struct net_device *dev)
-{
- struct bcm_sysport_priv *priv = netdev_priv(dev);
- unsigned long tx_bytes = 0, tx_packets = 0;
- struct bcm_sysport_tx_ring *ring;
- unsigned int q;
-
- for (q = 0; q < dev->num_tx_queues; q++) {
- ring = &priv->tx_rings[q];
- tx_bytes += ring->bytes;
- tx_packets += ring->packets;
- }
-
- dev->stats.tx_bytes = tx_bytes;
- dev->stats.tx_packets = tx_packets;
- return &dev->stats;
-}
-
static void bcm_sysport_netif_start(struct net_device *dev)
{
struct bcm_sysport_priv *priv = netdev_priv(dev);
@@ -1923,6 +1914,37 @@ static int bcm_sysport_stop(struct net_device *dev)
return 0;
}
+static void bcm_sysport_get_stats64(struct net_device *dev,
+ struct rtnl_link_stats64 *stats)
+{
+ struct bcm_sysport_priv *priv = netdev_priv(dev);
+ struct bcm_sysport_stats *stats64 = &priv->stats64;
+ struct bcm_sysport_tx_ring *ring;
+ u64 tx_packets = 0, tx_bytes = 0;
+ unsigned int start;
+ unsigned int q;
+
+ netdev_stats_to_stats64(stats, &dev->stats);
+
+ for (q = 0; q < dev->num_tx_queues; q++) {
+ ring = &priv->tx_rings[q];
+ do {
+ start = u64_stats_fetch_begin_irq(&stats64->syncp);
+ tx_bytes += ring->bytes;
+ tx_packets += ring->packets;
+ } while (u64_stats_fetch_retry_irq(&stats64->syncp, start));
+ }
+
+ stats->tx_packets = tx_packets;
+ stats->tx_bytes = tx_bytes;
+
+ do {
+ start = u64_stats_fetch_begin_irq(&stats64->syncp);
+ stats->rx_packets = stats64->rx_packets;
+ stats->rx_bytes = stats64->rx_bytes;
+ } while (u64_stats_fetch_retry_irq(&stats64->syncp, start));
+}
+
static const struct ethtool_ops bcm_sysport_ethtool_ops = {
.get_drvinfo = bcm_sysport_get_drvinfo,
.get_msglevel = bcm_sysport_get_msglvl,
@@ -1950,7 +1972,7 @@ static int bcm_sysport_stop(struct net_device *dev)
#ifdef CONFIG_NET_POLL_CONTROLLER
.ndo_poll_controller = bcm_sysport_poll_controller,
#endif
- .ndo_get_stats = bcm_sysport_get_nstats,
+ .ndo_get_stats64 = bcm_sysport_get_stats64,
};
#define REV_FMT "v%2x.%02x"
diff --git a/drivers/net/ethernet/broadcom/bcmsysport.h b/drivers/net/ethernet/broadcom/bcmsysport.h
index 77a51c1..c03a176 100644
--- a/drivers/net/ethernet/broadcom/bcmsysport.h
+++ b/drivers/net/ethernet/broadcom/bcmsysport.h
@@ -657,6 +657,9 @@ struct bcm_sysport_stats {
enum bcm_sysport_stat_type type;
/* reg offset from UMAC base for misc counters */
u16 reg_offset;
+ u64 rx_packets;
+ u64 rx_bytes;
+ struct u64_stats_sync syncp;
};
/* Software house keeping helper structure */
@@ -693,8 +696,8 @@ struct bcm_sysport_tx_ring {
struct bcm_sysport_cb *cbs; /* Transmit control blocks */
struct dma_desc *desc_cpu; /* CPU view of the descriptor */
struct bcm_sysport_priv *priv; /* private context backpointer */
- unsigned long packets; /* packets statistics */
- unsigned long bytes; /* bytes statistics */
+ u64 packets; /* packets statistics */
+ u64 bytes; /* bytes statistics */
};
/* Driver private structure */
@@ -743,5 +746,7 @@ struct bcm_sysport_priv {
/* Ethtool */
u32 msg_enable;
+ /* 64bit stats on 32bit/64bit Machine */
+ struct bcm_sysport_stats stats64;
};
#endif /* __BCM_SYSPORT_H */
--
1.9.1
^ permalink raw reply related
* [PATCH] drivers/net/wan/z85230.c: Use designated initializers
From: Kees Cook @ 2017-07-31 1:31 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev
In preparation for the randstruct gcc plugin performing randomization of
structures that are entirely function pointers, use designated initializers
so the compiler doesn't get angry.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
---
This is a prerequisite for the future randstruct fptr randomization. I'd
prefer to carry this in my gcc-plugin tree for v4.14 with an Ack from
someone on net-dev, or if possible, have it applied to v4.13 via net-dev.
Thanks!
---
drivers/net/wan/z85230.c | 30 ++++++++++++++----------------
1 file changed, 14 insertions(+), 16 deletions(-)
diff --git a/drivers/net/wan/z85230.c b/drivers/net/wan/z85230.c
index 2f0bd6955f33..deea41e96f01 100644
--- a/drivers/net/wan/z85230.c
+++ b/drivers/net/wan/z85230.c
@@ -483,11 +483,10 @@ static void z8530_status(struct z8530_channel *chan)
write_zsctrl(chan, RES_H_IUS);
}
-struct z8530_irqhandler z8530_sync =
-{
- z8530_rx,
- z8530_tx,
- z8530_status
+struct z8530_irqhandler z8530_sync = {
+ .rx = z8530_rx,
+ .tx = z8530_tx,
+ .status = z8530_status,
};
EXPORT_SYMBOL(z8530_sync);
@@ -605,15 +604,15 @@ static void z8530_dma_status(struct z8530_channel *chan)
}
static struct z8530_irqhandler z8530_dma_sync = {
- z8530_dma_rx,
- z8530_dma_tx,
- z8530_dma_status
+ .rx = z8530_dma_rx,
+ .tx = z8530_dma_tx,
+ .status = z8530_dma_status,
};
static struct z8530_irqhandler z8530_txdma_sync = {
- z8530_rx,
- z8530_dma_tx,
- z8530_dma_status
+ .rx = z8530_rx,
+ .tx = z8530_dma_tx,
+ .status = z8530_dma_status,
};
/**
@@ -678,11 +677,10 @@ static void z8530_status_clear(struct z8530_channel *chan)
write_zsctrl(chan, RES_H_IUS);
}
-struct z8530_irqhandler z8530_nop=
-{
- z8530_rx_clear,
- z8530_tx_clear,
- z8530_status_clear
+struct z8530_irqhandler z8530_nop = {
+ .rx = z8530_rx_clear,
+ .tx = z8530_tx_clear,
+ .status = z8530_status_clear,
};
--
2.7.4
--
Kees Cook
Pixel Security
^ permalink raw reply related
* RE: [PATCH net-next] net: fec: Allow reception of frames bigger than 1522 bytes
From: Andy Duan @ 2017-07-31 1:41 UTC (permalink / raw)
To: Andrew Lunn, David Miller; +Cc: netdev
In-Reply-To: <1501436165-20259-1-git-send-email-andrew@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch> Sent: Monday, July 31, 2017 1:36 AM
>The FEC Receive Control Register has a 14 bit field indicating the longest frame
>that my be received. It is being set to 1522. Frames longer than this are
My -> may
>discarded, but counted as being in error.
>
>When using DSA, frames from the switch has an additional header, either 4 or
>8 bytes if a Marvell switch is used. Thus a full MTU frame of 1522 bytes
>received by the switch on a port becomes 1530 bytes when passed to the host
>via the FEC interface.
>
>Change the maximum receive size to 2048 - 64, where 64 is the maximum
>rx_alignment applied on the receive buffer for AVB capable FEC cores. Use this
>value also for the maximum receive buffer size. The driver is already allocating
>a receive SKB of 2048 bytes, so this change should not have any significant
>effects.
>
>Tested on imx51, imx6, vf610.
>
>Signed-off-by: Andrew Lunn <andrew@lunn.ch>
>---
> drivers/net/ethernet/freescale/fec_main.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
>diff --git a/drivers/net/ethernet/freescale/fec_main.c
>b/drivers/net/ethernet/freescale/fec_main.c
>index a6e323f15637..47ee74a17a9f 100644
>--- a/drivers/net/ethernet/freescale/fec_main.c
>+++ b/drivers/net/ethernet/freescale/fec_main.c
>@@ -173,10 +173,12 @@ MODULE_PARM_DESC(macaddr, "FEC Ethernet
>MAC address"); #endif /* CONFIG_M5272 */
>
> /* The FEC stores dest/src/type/vlan, data, and checksum for receive packets.
>+ *
>+ * 2048 byte skbufs are allocated. However, alignment requirements
>+ * varies between FEC variants. Worst case is 64, so round down by 64.
> */
>-#define PKT_MAXBUF_SIZE 1522
>+#define PKT_MAXBUF_SIZE (round_down(2048 - 64, 64))
> #define PKT_MINBUF_SIZE 64
>-#define PKT_MAXBLR_SIZE 1536
>
> /* FEC receive acceleration */
> #define FEC_RACC_IPDIS (1 << 1)
>@@ -851,7 +853,7 @@ static void fec_enet_enable_ring(struct net_device
>*ndev)
> for (i = 0; i < fep->num_rx_queues; i++) {
> rxq = fep->rx_queue[i];
> writel(rxq->bd.dma, fep->hwp + FEC_R_DES_START(i));
>- writel(PKT_MAXBLR_SIZE, fep->hwp + FEC_R_BUFF_SIZE(i));
>+ writel(PKT_MAXBUF_SIZE, fep->hwp + FEC_R_BUFF_SIZE(i));
>
> /* enable DMA1/2 */
> if (i)
>--
>2.13.2
^ permalink raw reply
* RE: [PATCH net-next] net: fec: Issue error for missing but expected PHY
From: Andy Duan @ 2017-07-31 1:42 UTC (permalink / raw)
To: Andrew Lunn, David Miller; +Cc: netdev
In-Reply-To: <1501445466-23518-1-git-send-email-andrew@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch> Sent: Monday, July 31, 2017 4:11 AM
>If the PHY is missing but expected, e.g. because of a typ0 in the dt file, it is not
>possible to open the interface. ip link returns:
>
>RTNETLINK answers: No such device
>
>It is not very obvious what the problem is. Add a netdev_err() in this case to
>make it easier to debug the issue.
>
>[ 21.409385] fec 2188000.ethernet eth0: Unable to connect to phy
>RTNETLINK answers: No such device
>
>Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Fugang Duan <fugang.duan@nxp.com>
>---
> drivers/net/ethernet/freescale/fec_main.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/net/ethernet/freescale/fec_main.c
>b/drivers/net/ethernet/freescale/fec_main.c
>index cc0c2a58c4de..c5995f07f821 100644
>--- a/drivers/net/ethernet/freescale/fec_main.c
>+++ b/drivers/net/ethernet/freescale/fec_main.c
>@@ -1907,8 +1907,10 @@ static int fec_enet_mii_probe(struct net_device
>*ndev)
> phy_dev = of_phy_connect(ndev, fep->phy_node,
> &fec_enet_adjust_link, 0,
> fep->phy_interface);
>- if (!phy_dev)
>+ if (!phy_dev) {
>+ netdev_err(ndev, "Unable to connect to phy\n");
> return -ENODEV;
>+ }
> } else {
> /* check for attached phy */
> for (phy_id = 0; (phy_id < PHY_MAX_ADDR); phy_id++) {
>--
>2.13.2
^ permalink raw reply
* Re: [PATCH v2 net-next 0/4] net: dsa: lan9303: Fix MDIO issues.
From: David Miller @ 2017-07-31 2:23 UTC (permalink / raw)
To: privat; +Cc: andrew, vivien.didelot, f.fainelli, netdev, linux-kernel, kernel
In-Reply-To: <20170730175856.4784-1-privat@egil-hjelmeland.no>
From: Egil Hjelmeland <privat@egil-hjelmeland.no>
Date: Sun, 30 Jul 2017 19:58:52 +0200
> This series fix the MDIO interface for the lan9303 DSA driver.
> Bugs found after testing on actual HW.
>
> This series is extracted from the first patch of my first large
> series. Significant changes from that version are:
> - use mdiobus_write_nested, mdiobus_read_nested.
> - EXPORT lan9303_indirect_phy_ops
>
> Unfortunately I do not have access to i2c based system for
> testing.
>
> Changes from first version:
> - Change EXPORT_SYMBOL to EXPORT_SYMBOL_GPL
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next] net: fec: Issue error for missing but expected PHY
From: David Miller @ 2017-07-31 2:26 UTC (permalink / raw)
To: andrew; +Cc: netdev, fugang.duan
In-Reply-To: <1501445466-23518-1-git-send-email-andrew@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Sun, 30 Jul 2017 22:11:06 +0200
> If the PHY is missing but expected, e.g. because of a typ0 in the dt
> file, it is not possible to open the interface. ip link returns:
>
> RTNETLINK answers: No such device
>
> It is not very obvious what the problem is. Add a netdev_err() in this
> case to make it easier to debug the issue.
>
> [ 21.409385] fec 2188000.ethernet eth0: Unable to connect to phy
> RTNETLINK answers: No such device
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: fec: Allow reception of frames bigger than 1522 bytes
From: David Miller @ 2017-07-31 2:26 UTC (permalink / raw)
To: andrew; +Cc: netdev, fugang.duan
In-Reply-To: <1501436165-20259-1-git-send-email-andrew@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Sun, 30 Jul 2017 19:36:05 +0200
> The FEC Receive Control Register has a 14 bit field indicating the
> longest frame that my be received. It is being set to 1522. Frames
> longer than this are discarded, but counted as being in error.
>
> When using DSA, frames from the switch has an additional header,
> either 4 or 8 bytes if a Marvell switch is used. Thus a full MTU frame
> of 1522 bytes received by the switch on a port becomes 1530 bytes when
> passed to the host via the FEC interface.
>
> Change the maximum receive size to 2048 - 64, where 64 is the maximum
> rx_alignment applied on the receive buffer for AVB capable FEC
> cores. Use this value also for the maximum receive buffer size. The
> driver is already allocating a receive SKB of 2048 bytes, so this
> change should not have any significant effects.
>
> Tested on imx51, imx6, vf610.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Applied with commit log message typo fixed.
^ permalink raw reply
* Re: [PATCH net-next v12 1/4] net netlink: Add new type NLA_BITFIELD32
From: David Ahern @ 2017-07-31 2:27 UTC (permalink / raw)
To: Jamal Hadi Salim, Jiri Pirko
Cc: davem, netdev, xiyou.wangcong, eric.dumazet, horms
In-Reply-To: <98edc93f-b5d9-e73f-ff00-9403e8362f80@mojatatu.com>
On 7/30/17 1:59 PM, Jamal Hadi Salim wrote:
> On D. Ahern: I dont think we are disagreeing anymore on the need to
> generalize the check. He is saying it should be a helper and I already
> had the validation data; either works. I dont see the gapping need
> to remove the validation data.
I never disagreed on general code; I have always disagreed on validating
values as part of the policy check.
^ permalink raw reply
* Re: [PATCH net-next] net: fec: Allow reception of frames bigger than 1522 bytes
From: Andrew Lunn @ 2017-07-31 2:27 UTC (permalink / raw)
To: David Miller; +Cc: netdev, fugang.duan
In-Reply-To: <20170730.192629.124814765201077334.davem@davemloft.net>
On Sun, Jul 30, 2017 at 07:26:29PM -0700, David Miller wrote:
> From: Andrew Lunn <andrew@lunn.ch>
> Date: Sun, 30 Jul 2017 19:36:05 +0200
>
> > The FEC Receive Control Register has a 14 bit field indicating the
> > longest frame that my be received. It is being set to 1522. Frames
> > longer than this are discarded, but counted as being in error.
> >
> > When using DSA, frames from the switch has an additional header,
> > either 4 or 8 bytes if a Marvell switch is used. Thus a full MTU frame
> > of 1522 bytes received by the switch on a port becomes 1530 bytes when
> > passed to the host via the FEC interface.
> >
> > Change the maximum receive size to 2048 - 64, where 64 is the maximum
> > rx_alignment applied on the receive buffer for AVB capable FEC
> > cores. Use this value also for the maximum receive buffer size. The
> > driver is already allocating a receive SKB of 2048 bytes, so this
> > change should not have any significant effects.
> >
> > Tested on imx51, imx6, vf610.
> >
> > Signed-off-by: Andrew Lunn <andrew@lunn.ch>
>
> Applied with commit log message typo fixed.
Hi David
Thanks for fixing the typo.
Andrew
^ permalink raw reply
* Re: [PATCH net-next v12 0/4] net sched actions: improve dump performance
From: David Miller @ 2017-07-31 2:28 UTC (permalink / raw)
To: jhs; +Cc: netdev, jiri, xiyou.wangcong, eric.dumazet, horms, dsahern
In-Reply-To: <1501435492-28301-1-git-send-email-jhs@emojatatu.com>
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net] ipv6: set fc_protocol with 0 when rtm_protocol is RTPROT_REDIRECT
From: David Ahern @ 2017-07-31 2:35 UTC (permalink / raw)
To: Xin Long, network dev; +Cc: davem, grawity
In-Reply-To: <e9342d18b97fc227cacc19db1b43f4c7350eed3f.1501419097.git.lucien.xin@gmail.com>
On 7/30/17 6:51 AM, Xin Long wrote:
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index 4d30c96..187580f 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -2912,9 +2912,11 @@ static int rtm_to_fib6_config(struct sk_buff *skb, struct nlmsghdr *nlh,
> cfg->fc_dst_len = rtm->rtm_dst_len;
> cfg->fc_src_len = rtm->rtm_src_len;
> cfg->fc_flags = RTF_UP;
> - cfg->fc_protocol = rtm->rtm_protocol;
> cfg->fc_type = rtm->rtm_type;
>
> + if (rtm->rtm_protocol != RTPROT_REDIRECT)
> + cfg->fc_protocol = rtm->rtm_protocol;
> +
> if (rtm->rtm_type == RTN_UNREACHABLE ||
> rtm->rtm_type == RTN_BLACKHOLE ||
> rtm->rtm_type == RTN_PROHIBIT ||
Did you look at removing this hunk from rt6_fill_node:
if (rt->rt6i_flags & RTF_DYNAMIC)
rtm->rtm_protocol = RTPROT_REDIRECT;
else if (rt->rt6i_flags & RTF_ADDRCONF) {
if (rt->rt6i_flags & (RTF_DEFAULT | RTF_ROUTEINFO))
rtm->rtm_protocol = RTPROT_RA;
else
rtm->rtm_protocol = RTPROT_KERNEL;
}
And have rtm_protocol set properly on the route when it is installed?
^ permalink raw reply
* [PATCH] Cipso: cipso_v4_optptr enter infinite loop
From: Yujuan Qi @ 2017-07-31 3:23 UTC (permalink / raw)
To: Paul Moore, David S. Miller
Cc: Ryder Lee, yujuan.qi, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Casey Schaufler
From: "yujuan.qi" <yujuan.qi-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
in for(),if((optlen > 0) && (optptr[1] == 0)), enter infinite loop.
Test: receive a packet which the ip length > 20 and the first byte of ip option is 0, produce this issue
Signed-off-by: yujuan.qi <yujuan.qi-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
---
net/ipv4/cipso_ipv4.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/cipso_ipv4.c b/net/ipv4/cipso_ipv4.c
index ae20616..0d1e07d 100644
--- a/net/ipv4/cipso_ipv4.c
+++ b/net/ipv4/cipso_ipv4.c
@@ -1523,9 +1523,17 @@ unsigned char *cipso_v4_optptr(const struct sk_buff *skb)
int taglen;
for (optlen = iph->ihl*4 - sizeof(struct iphdr); optlen > 0; ) {
- if (optptr[0] == IPOPT_CIPSO)
+ switch (optptr[0]) {
+ case IPOPT_CIPSO:
return optptr;
- taglen = optptr[1];
+ case IPOPT_END:
+ return NULL;
+ case IPOPT_NOOP:
+ taglen = 1;
+ break;
+ default:
+ taglen = optptr[1];
+ }
optlen -= taglen;
optptr += taglen;
}
--
1.9.1
^ permalink raw reply related
* RE: [PATCH V3 net-next] TLP: Don't reschedule PTO when there's one outstanding TLP retransmission
From: maowenan @ 2017-07-31 3:29 UTC (permalink / raw)
To: Neal Cardwell
Cc: Netdev, David Miller, Yuchung Cheng, Nandita Dukkipati,
weiyongjun (A), Chenweilong, Wangkefeng (Kevin)
In-Reply-To: <CADVnQykeDvPCQqvoox-oQkm5FdCvLQRvxZKC+TVmG7g-9CEoxw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1446 bytes --]
> -----Original Message-----
> From: Neal Cardwell [mailto:ncardwell@google.com]
> Sent: Saturday, July 29, 2017 10:04 PM
> To: maowenan
> Cc: Netdev; David Miller; Yuchung Cheng; Nandita Dukkipati; weiyongjun (A);
> Chenweilong; Wangkefeng (Kevin)
> Subject: Re: [PATCH V3 net-next] TLP: Don't reschedule PTO when there's one
> outstanding TLP retransmission
>
> On Fri, Jul 28, 2017 at 9:39 PM, maowenan <maowenan@huawei.com> wrote:
> > [Mao Wenan]ok, We have reproduced this issue with packetdrill
> > yesterday, there is no the same issue when TLP send new data packet,
> > RTO will be fired and retransmit packet.
>
> That's great to hear that you were able to reproduce this with packetdrill.
> Would you be able to share the packetdrill scripts that reproduce your issues? I
> would like to make sure our proposed patch addresses your scenarios as well.
[Mao Wenan]please refer to the attachment, test.pkt is packetdrill script.
In test.pcap, packet number 17 is the TLP probe, packet number 218 is the
retransmission packet because client don't send data packet to server.
From the capture time, there are about 6 seconds the retransmission
packet can be sent, and this time can be added more as long as client
send data packet continually.
I have reproduced this issue in Linux 4.13-rc3, 3.10, 4.1. Please check the timing
When you use test.pkt to reproduce in your environment.
>
> thanks,
> neal
[-- Attachment #2: test.pcap --]
[-- Type: application/octet-stream, Size: 135408 bytes --]
[-- Attachment #3: test.pkt --]
[-- Type: application/octet-stream, Size: 9892 bytes --]
0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+0 setsockopt(3, SOL_SOCKET, SO_SNDBUF, [0x4000], 4) = 0
+0 setsockopt(3, SOL_SOCKET, SO_RCVBUF, [0x800000], 4) = 0
+0 bind(3, ..., ...) = 0
+0 listen(3, 1) = 0
+0 < S 0:0(0) win 32792 <mss 1000,sackOK,nop,nop,nop,wscale 7>
+0 > S. 0:0(0) ack 1 <mss 1460,nop,nop,sackOK,nop,wscale 2>
+.020 < . 1:1(0) ack 1 win 257
+0 accept(3, ..., ...) = 4
// Send 10 MSS.
+0 write(4, ..., 10000) = 10000
+0 > . 1:2001(2000) ack 1
+0 > . 2001:4001(2000) ack 1
+0 > . 4001:6001(2000) ack 1
+0 > . 6001:8001(2000) ack 1
+0 > P. 8001:10001(2000) ack 1
// Incoming data arrives
+.010 < . 1:1001(1000) ack 1 win 257
* > . 10001:10001(0) ack 1001
+0 read(4, ..., 1000) = 1000
+.010 < . 1001:2001(1000) ack 1 win 257
* > . 10001:10001(0) ack 2001
+0 read(4, ..., 1000) = 1000
+.010 < . 2001:3001(1000) ack 1 win 257
* > . 10001:10001(0) ack 3001
+0 read(4, ..., 1000) = 1000
+.010 < . 3001:4001(1000) ack 1 win 257
* > . 10001:10001(0) ack 4001
// At 2*RTT after the last transmit, send a TLP loss probe
* > P. 9001:10001(1000) ack 4001
+0 read(4, ..., 1000) = 1000
+.05 < . 4001:5001(1000) ack 1 win 257
* > . 10001:10001(0) ack 5001
+.05 < . 5001:6001(1000) ack 1 win 257
* > . 10001:10001(0) ack 6001
+.05 < . 6001:7001(1000) ack 1 win 257
* > . 10001:10001(0) ack 7001
+.05 < . 7001:8001(1000) ack 1 win 257
* > . 10001:10001(0) ack 8001
+0 read(4, ..., 4000) = 4000
+.05 < . 8001:9001(1000) ack 1 win 257
* > . 10001:10001(0) ack 9001
+.05 < . 9001:10001(1000) ack 1 win 257
* > . 10001:10001(0) ack 10001
+.05 < . 10001:11001(1000) ack 1 win 257
* > . 10001:10001(0) ack 11001
+.05 < . 11001:12001(1000) ack 1 win 257
* > . 10001:10001(0) ack 12001
+0 read(4, ..., 4000) = 4000
+.05 < . 12001:13001(1000) ack 1 win 257
* > . 10001:10001(0) ack 13001
+.05 < . 13001:14001(1000) ack 1 win 257
* > . 10001:10001(0) ack 14001
+.05 < . 14001:15001(1000) ack 1 win 257
* > . 10001:10001(0) ack 15001
+.05 < . 15001:16001(1000) ack 1 win 257
* > . 10001:10001(0) ack 16001
+0 read(4, ..., 4000) = 4000
+.05 < . 16001:17001(1000) ack 1 win 257
* > . 10001:10001(0) ack 17001
+.05 < . 17001:18001(1000) ack 1 win 257
* > . 10001:10001(0) ack 18001
+.05 < . 18001:19001(1000) ack 1 win 257
* > . 10001:10001(0) ack 19001
+.05 < . 19001:20001(1000) ack 1 win 257
* > . 10001:10001(0) ack 20001
+0 read(4, ..., 4000) = 4000
+.05 < . 20001:21001(1000) ack 1 win 257
* > . 10001:10001(0) ack 21001
+.05 < . 21001:22001(1000) ack 1 win 257
* > . 10001:10001(0) ack 22001
+.05 < . 22001:23001(1000) ack 1 win 257
* > . 10001:10001(0) ack 23001
+.05 < . 23001:24001(1000) ack 1 win 257
* > . 10001:10001(0) ack 24001
+0 read(4, ..., 4000) = 4000
+.05 < . 24001:25001(1000) ack 1 win 257
* > . 10001:10001(0) ack 25001
+.05 < . 25001:26001(1000) ack 1 win 257
* > . 10001:10001(0) ack 26001
+.05 < . 26001:27001(1000) ack 1 win 257
* > . 10001:10001(0) ack 27001
+.05 < . 27001:28001(1000) ack 1 win 257
* > . 10001:10001(0) ack 28001
+0 read(4, ..., 4000) = 4000
+.05 < . 28001:29001(1000) ack 1 win 257
* > . 10001:10001(0) ack 29001
+.05 < . 29001:30001(1000) ack 1 win 257
* > . 10001:10001(0) ack 30001
+.05 < . 30001:31001(1000) ack 1 win 257
* > . 10001:10001(0) ack 31001
+.05 < . 31001:32001(1000) ack 1 win 257
* > . 10001:10001(0) ack 32001
+0 read(4, ..., 4000) = 4000
+.05 < . 32001:33001(1000) ack 1 win 257
* > . 10001:10001(0) ack 33001
+.05 < . 33001:34001(1000) ack 1 win 257
* > . 10001:10001(0) ack 34001
+.05 < . 34001:35001(1000) ack 1 win 257
* > . 10001:10001(0) ack 35001
+.05 < . 35001:36001(1000) ack 1 win 257
* > . 10001:10001(0) ack 36001
+0 read(4, ..., 4000) = 4000
+.05 < . 36001:37001(1000) ack 1 win 257
* > . 10001:10001(0) ack 37001
+.05 < . 37001:38001(1000) ack 1 win 257
* > . 10001:10001(0) ack 38001
+.05 < . 38001:39001(1000) ack 1 win 257
* > . 10001:10001(0) ack 39001
+.05 < . 39001:40001(1000) ack 1 win 257
* > . 10001:10001(0) ack 40001
+0 read(4, ..., 4000) = 4000
+.05 < . 40001:41001(1000) ack 1 win 257
* > . 10001:10001(0) ack 41001
+.05 < . 41001:42001(1000) ack 1 win 257
* > . 10001:10001(0) ack 42001
+.05 < . 42001:43001(1000) ack 1 win 257
* > . 10001:10001(0) ack 43001
+.05 < . 43001:44001(1000) ack 1 win 257
* > . 10001:10001(0) ack 44001
+0 read(4, ..., 4000) = 4000
+.05 < . 44001:45001(1000) ack 1 win 257
* > . 10001:10001(0) ack 45001
+.05 < . 45001:46001(1000) ack 1 win 257
* > . 10001:10001(0) ack 46001
+.05 < . 46001:47001(1000) ack 1 win 257
* > . 10001:10001(0) ack 47001
+.05 < . 47001:48001(1000) ack 1 win 257
* > . 10001:10001(0) ack 48001
+0 read(4, ..., 4000) = 4000
+.05 < . 48001:49001(1000) ack 1 win 257
* > . 10001:10001(0) ack 49001
+.05 < . 49001:50001(1000) ack 1 win 257
* > . 10001:10001(0) ack 50001
+.05 < . 50001:51001(1000) ack 1 win 257
* > . 10001:10001(0) ack 51001
+.05 < . 51001:52001(1000) ack 1 win 257
* > . 10001:10001(0) ack 52001
+0 read(4, ..., 4000) = 4000
+.05 < . 52001:53001(1000) ack 1 win 257
* > . 10001:10001(0) ack 53001
+.05 < . 53001:54001(1000) ack 1 win 257
* > . 10001:10001(0) ack 54001
+.05 < . 54001:55001(1000) ack 1 win 257
* > . 10001:10001(0) ack 55001
+.05 < . 55001:56001(1000) ack 1 win 257
* > . 10001:10001(0) ack 56001
+0 read(4, ..., 4000) = 4000
+.05 < . 56001:57001(1000) ack 1 win 257
* > . 10001:10001(0) ack 57001
+.05 < . 57001:58001(1000) ack 1 win 257
* > . 10001:10001(0) ack 58001
+.05 < . 58001:59001(1000) ack 1 win 257
* > . 10001:10001(0) ack 59001
+.05 < . 59001:60001(1000) ack 1 win 257
* > . 10001:10001(0) ack 60001
+0 read(4, ..., 4000) = 4000
+.05 < . 60001:61001(1000) ack 1 win 257
* > . 10001:10001(0) ack 61001
+.05 < . 61001:62001(1000) ack 1 win 257
* > . 10001:10001(0) ack 62001
+.05 < . 62001:63001(1000) ack 1 win 257
* > . 10001:10001(0) ack 63001
+.05 < . 63001:64001(1000) ack 1 win 257
* > . 10001:10001(0) ack 64001
+0 read(4, ..., 4000) = 4000
+.05 < . 64001:65001(1000) ack 1 win 257
* > . 10001:10001(0) ack 65001
+.05 < . 65001:66001(1000) ack 1 win 257
* > . 10001:10001(0) ack 66001
+.05 < . 66001:67001(1000) ack 1 win 257
* > . 10001:10001(0) ack 67001
+.05 < . 67001:68001(1000) ack 1 win 257
* > . 10001:10001(0) ack 68001
+0 read(4, ..., 4000) = 4000
+.05 < . 68001:69001(1000) ack 1 win 257
* > . 10001:10001(0) ack 69001
+.05 < . 69001:70001(1000) ack 1 win 257
* > . 10001:10001(0) ack 70001
+.05 < . 70001:71001(1000) ack 1 win 257
* > . 10001:10001(0) ack 71001
+.05 < . 71001:72001(1000) ack 1 win 257
* > . 10001:10001(0) ack 72001
+0 read(4, ..., 4000) = 4000
+.05 < . 72001:73001(1000) ack 1 win 257
* > . 10001:10001(0) ack 73001
+.05 < . 73001:74001(1000) ack 1 win 257
* > . 10001:10001(0) ack 74001
+.05 < . 74001:75001(1000) ack 1 win 257
* > . 10001:10001(0) ack 75001
+.05 < . 75001:76001(1000) ack 1 win 257
* > . 10001:10001(0) ack 76001
+0 read(4, ..., 4000) = 4000
+.05 < . 76001:77001(1000) ack 1 win 257
* > . 10001:10001(0) ack 77001
+.05 < . 77001:78001(1000) ack 1 win 257
* > . 10001:10001(0) ack 78001
+.05 < . 78001:79001(1000) ack 1 win 257
* > . 10001:10001(0) ack 79001
+.05 < . 79001:80001(1000) ack 1 win 257
* > . 10001:10001(0) ack 80001
+0 read(4, ..., 4000) = 4000
+.05 < . 80001:81001(1000) ack 1 win 257
* > . 10001:10001(0) ack 81001
+.05 < . 81001:82001(1000) ack 1 win 257
* > . 10001:10001(0) ack 82001
+.05 < . 82001:83001(1000) ack 1 win 257
* > . 10001:10001(0) ack 83001
+.05 < . 83001:84001(1000) ack 1 win 257
* > . 10001:10001(0) ack 84001
+0 read(4, ..., 4000) = 4000
+.05 < . 84001:85001(1000) ack 1 win 257
* > . 10001:10001(0) ack 85001
+.05 < . 85001:86001(1000) ack 1 win 257
* > . 10001:10001(0) ack 86001
+.05 < . 86001:87001(1000) ack 1 win 257
* > . 10001:10001(0) ack 87001
+.05 < . 87001:88001(1000) ack 1 win 257
* > . 10001:10001(0) ack 88001
+0 read(4, ..., 4000) = 4000
+.05 < . 88001:89001(1000) ack 1 win 257
* > . 10001:10001(0) ack 89001
+.05 < . 89001:90001(1000) ack 1 win 257
* > . 10001:10001(0) ack 90001
+.05 < . 90001:91001(1000) ack 1 win 257
* > . 10001:10001(0) ack 91001
+.05 < . 91001:92001(1000) ack 1 win 257
* > . 10001:10001(0) ack 92001
+0 read(4, ..., 4000) = 4000
+.05 < . 92001:93001(1000) ack 1 win 257
* > . 10001:10001(0) ack 93001
+.05 < . 93001:94001(1000) ack 1 win 257
* > . 10001:10001(0) ack 94001
+.05 < . 94001:95001(1000) ack 1 win 257
* > . 10001:10001(0) ack 95001
+.05 < . 95001:96001(1000) ack 1 win 257
* > . 10001:10001(0) ack 96001
+0 read(4, ..., 4000) = 4000
+.05 < . 96001:97001(1000) ack 1 win 257
* > . 10001:10001(0) ack 97001
+.05 < . 97001:98001(1000) ack 1 win 257
* > . 10001:10001(0) ack 98001
+.05 < . 98001:99001(1000) ack 1 win 257
* > . 10001:10001(0) ack 99001
+.05 < . 99001:100001(1000) ack 1 win 257
* > . 10001:10001(0) ack 100001
+0 read(4, ..., 4000) = 4000
+.05 < . 100001:101001(1000) ack 1 win 257
* > . 10001:10001(0) ack 101001
+.05 < . 101001:102001(1000) ack 1 win 257
* > . 10001:10001(0) ack 102001
+.05 < . 102001:103001(1000) ack 1 win 257
* > . 10001:10001(0) ack 103001
+.05 < . 103001:104001(1000) ack 1 win 257
* > . 10001:10001(0) ack 104001
+0 read(4, ..., 4000) = 4000
//server retransmit one packet
* > . 1:1001(1000) ack 104001
^ permalink raw reply
* Re: [PATCH net] ipv6: set fc_protocol with 0 when rtm_protocol is RTPROT_REDIRECT
From: Xin Long @ 2017-07-31 3:31 UTC (permalink / raw)
To: David Ahern; +Cc: network dev, davem, Mantas Mikulėnas
In-Reply-To: <9fcbffcb-4a14-764c-7fe4-2108b8944c17@gmail.com>
On Mon, Jul 31, 2017 at 2:35 PM, David Ahern <dsahern@gmail.com> wrote:
> On 7/30/17 6:51 AM, Xin Long wrote:
>> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
>> index 4d30c96..187580f 100644
>> --- a/net/ipv6/route.c
>> +++ b/net/ipv6/route.c
>> @@ -2912,9 +2912,11 @@ static int rtm_to_fib6_config(struct sk_buff *skb, struct nlmsghdr *nlh,
>> cfg->fc_dst_len = rtm->rtm_dst_len;
>> cfg->fc_src_len = rtm->rtm_src_len;
>> cfg->fc_flags = RTF_UP;
>> - cfg->fc_protocol = rtm->rtm_protocol;
>> cfg->fc_type = rtm->rtm_type;
>>
>> + if (rtm->rtm_protocol != RTPROT_REDIRECT)
>> + cfg->fc_protocol = rtm->rtm_protocol;
>> +
>> if (rtm->rtm_type == RTN_UNREACHABLE ||
>> rtm->rtm_type == RTN_BLACKHOLE ||
>> rtm->rtm_type == RTN_PROHIBIT ||
Hi, David
>
> Did you look at removing this hunk from rt6_fill_node:
>
> if (rt->rt6i_flags & RTF_DYNAMIC)
> rtm->rtm_protocol = RTPROT_REDIRECT;
> else if (rt->rt6i_flags & RTF_ADDRCONF) {
> if (rt->rt6i_flags & (RTF_DEFAULT | RTF_ROUTEINFO))
> rtm->rtm_protocol = RTPROT_RA;
> else
> rtm->rtm_protocol = RTPROT_KERNEL;
> }
The issue seems to affect "ip -6 route flush all" as well, not only cache
since 'else if {}' also causes rtm proto being different from rt6 proto.
>
> And have rtm_protocol set properly on the route when it is installed?
The codes not keeping rtm proto consistent with rt6 proto day 1,
any idea on why it didn't use rt6 proto in kernel properly?
Thanks.
^ permalink raw reply
* Re: [PATCH v5 net-next] net: systemport: Support 64bit statistics
From: Florian Fainelli @ 2017-07-31 3:45 UTC (permalink / raw)
To: Jianming.qiao, davem, netdev
In-Reply-To: <1501459275-7635-1-git-send-email-jqiaoulk@gmail.com>
On July 30, 2017 5:01:15 PM PDT, "Jianming.qiao" <jqiaoulk@gmail.com> wrote:
>When using Broadcom Systemport device in 32bit Platform, ifconfig can
>only report up to 4G tx,rx status, which will be wrapped to 0 when the
>number of incoming or outgoing packets exceeds 4G, only taking
>around 2 hours in busy network environment (such as streaming).
>Therefore, it makes hard for network diagnostic tool to get reliable
>statistical result, so the patch is used to add 64bit support for
>Broadcom Systemport device in 32bit Platform.
>
>Signed-off-by: Jianming.qiao <kiki-good@hotmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* Re: [patch net-next 04/20] net: sched: use tcf_exts_has_actions in tcf_exts_exec
From: Jiri Pirko @ 2017-07-31 6:36 UTC (permalink / raw)
To: Jamal Hadi Salim; +Cc: netdev, davem, xiyou.wangcong, daniel, mlxsw
In-Reply-To: <c157148b-2e6c-6934-2d54-04d42a0a262c@mojatatu.com>
Sun, Jul 30, 2017 at 09:48:24PM CEST, jhs@mojatatu.com wrote:
>I am probably missing something. All those changes to just
>replace "if (exts->nr_actions)" with "if (tcf_exts_has_actions(exts))" ?
That is what the description says :)
>
>cheers,
>jamal
>
>On 17-07-28 10:40 AM, Jiri Pirko wrote:
>> From: Jiri Pirko <jiri@mellanox.com>
>>
>> Use the tcf_exts_has_actions helper instead or directly testing
>> exts->nr_actions in tcf_exts_exec.
>>
>> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [PATCH net-next v12 1/4] net netlink: Add new type NLA_BITFIELD32
From: Jiri Pirko @ 2017-07-31 6:38 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: davem, netdev, xiyou.wangcong, eric.dumazet, horms, dsahern
In-Reply-To: <98edc93f-b5d9-e73f-ff00-9403e8362f80@mojatatu.com>
Sun, Jul 30, 2017 at 09:59:10PM CEST, jhs@mojatatu.com wrote:
>Jiri,
>
>This is getting exhausting, seriously.
>I posted the code you are commenting one two days ago so i dont have to
>repost.
And I commented on the "*u32 = *u32" thing. But you ignored it. Pardon
me for mentioning that again now :/
>
>On D. Ahern: I dont think we are disagreeing anymore on the need to
>generalize the check. He is saying it should be a helper and I already
>had the validation data; either works. I dont see the gapping need
>to remove the validation data.
DavidA? Your opinion.
^ permalink raw reply
* Re: xfrm hardware offload for AH
From: Steffen Klassert @ 2017-07-31 6:40 UTC (permalink / raw)
To: David George; +Cc: netdev
In-Reply-To: <CAA1sxtx-OZhnyq1hBaOVUu0URk5FuZMev8Y8ut-pCgBHtvdgFw@mail.gmail.com>
Hi David.
On Thu, Jul 20, 2017 at 10:03:54AM +0200, David George wrote:
> Hi Steffen
>
> I am wondering if there would be any traction for adding xfrm hardware
> offload support for AH (something equivalent to esp4_offload). Is it
> something you have thought about?
I personally have no plans to add support for AH as this is not so
widely used anymore. But if you have a usecase, go for it. Patches are
welcome.
^ permalink raw reply
* [patch net-next 0/8] mlxsw: Various small fixes
From: Jiri Pirko @ 2017-07-31 7:27 UTC (permalink / raw)
To: netdev; +Cc: davem, idosch, petrm, mlxsw
From: Jiri Pirko <jiri@mellanox.com>
This patch series is to contribute several fixes for nits that I noticed while
working on mlxsw. The changes range from typo fixes to local improvements of
the code and have little in common besides being small in scope.
Petr Machata (8):
mlxsw: spectrum_acl: Fix a typo
mlxsw: reg.h: Fix a typo
mlxsw: spectrum_router: Fix a typo
mlxsw: Update specification of reg_ritr_type
mlxsw: reg.h: Namespace IP2ME registers
mlxsw: spectrum_router: Simplify a piece of code
mlxsw: spectrum_router: Clarify a piece of code
mlxsw: spectrum_router: Simplify a piece of code
drivers/net/ethernet/mellanox/mlxsw/reg.h | 18 +++++++++---------
drivers/net/ethernet/mellanox/mlxsw/spectrum_acl.c | 2 +-
drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c | 12 +++++-------
3 files changed, 15 insertions(+), 17 deletions(-)
--
2.9.3
^ 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