* Re: [PATCH net] net/mlx4_en: fix spurious timestamping callbacks
From: Or Gerlitz @ 2016-04-23 20:23 UTC (permalink / raw)
To: Eric Dumazet, David Miller; +Cc: netdev, Eugenia Emantayev, Eran Ben Elisha
In-Reply-To: <1461436546.7627.45.camel@edumazet-glaptop3.roam.corp.google.com>
On Sat, Apr 23, 2016 at 9:35 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> When multiple skb are TX-completed in a row, we might incorrectly keep
> a timestamp of a prior skb and cause extra work.
>
> Fixes: ec693d47010e8 ("net/mlx4_en: Add HW timestamping (TS) support")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Willem de Bruijn <willemb@google.com>
Eric, was that supposed to be Reported-by: or Signed-off-by: ...
FWIW, Dave, I wanted to use the opportunity and comment that this week
many of us gonna be on Passover vacation, so response rate should be
lower than usual
> drivers/net/ethernet/mellanox/mlx4/en_tx.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx4/en_tx.c b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
> index c0d7b7296236..a386f047c1af 100644
> --- a/drivers/net/ethernet/mellanox/mlx4/en_tx.c
> +++ b/drivers/net/ethernet/mellanox/mlx4/en_tx.c
> @@ -405,7 +405,6 @@ static bool mlx4_en_process_tx_cq(struct net_device *dev,
> u32 packets = 0;
> u32 bytes = 0;
> int factor = priv->cqe_factor;
> - u64 timestamp = 0;
> int done = 0;
> int budget = priv->tx_work_limit;
> u32 last_nr_txbb;
> @@ -445,9 +444,12 @@ static bool mlx4_en_process_tx_cq(struct net_device *dev,
> new_index = be16_to_cpu(cqe->wqe_index) & size_mask;
>
> do {
> + u64 timestamp = 0;
> +
> txbbs_skipped += last_nr_txbb;
> ring_index = (ring_index + last_nr_txbb) & size_mask;
> - if (ring->tx_info[ring_index].ts_requested)
> +
> + if (unlikely(ring->tx_info[ring_index].ts_requested))
> timestamp = mlx4_en_get_cqe_ts(cqe);
>
> /* free next descriptor */
>
>
^ permalink raw reply
* Re: [PATCH net-next 12/12] net/mlx5e: Disable link up on INIT HCA command
From: Or Gerlitz @ 2016-04-23 20:28 UTC (permalink / raw)
To: Saeed Mahameed
Cc: Ido Schimmel, Saeed Mahameed, David S. Miller, Linux Netdev List,
Or Gerlitz, Tal Alon, Eran Ben Elisha, Eugenia Emantayev,
Jiri Pirko, Elad Raz
In-Reply-To: <CALzJLG-AWFHnba=ysCAQLqCjFHo3L-sQTeW+NbpMg-X6PRtRPQ@mail.gmail.com>
On Sat, Apr 23, 2016 at 11:21 PM, Saeed Mahameed
<saeedm@dev.mellanox.co.il> wrote:
> On Sat, Apr 23, 2016 at 7:00 PM, Ido Schimmel <idosch@mellanox.com> wrote:
>> Also, why is this directed at net-next?
> it is kind of new behavior, and not a bug fix.
Saeed,
We should be aiming to patch the driver around this issue with
something that goes all the way back through -stable to the very 1st
upstream kernel supporting mlx5 EN --- the operational link doesn't go
down when instructed by the admin and this is an entry level
requirement from Ethernet of things (such as NIC and Switch ports).
^ permalink raw reply
* Re: [PATCH net-next 12/12] net/mlx5e: Disable link up on INIT HCA command
From: Saeed Mahameed @ 2016-04-23 21:24 UTC (permalink / raw)
To: Or Gerlitz
Cc: Ido Schimmel, Saeed Mahameed, David S. Miller, Linux Netdev List,
Or Gerlitz, Tal Alon, Eran Ben Elisha, Eugenia Emantayev,
Jiri Pirko, Elad Raz
In-Reply-To: <CAJ3xEMg_KFKRvCt5kBZzF_gmkLwg=2dZ=-FCjdbmgkX2-E0s3Q@mail.gmail.com>
On Sat, Apr 23, 2016 at 11:28 PM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
> On Sat, Apr 23, 2016 at 11:21 PM, Saeed Mahameed
> <saeedm@dev.mellanox.co.il> wrote:
>> On Sat, Apr 23, 2016 at 7:00 PM, Ido Schimmel <idosch@mellanox.com> wrote:
>
>>> Also, why is this directed at net-next?
>
>> it is kind of new behavior, and not a bug fix.
>
> Saeed,
>
> We should be aiming to patch the driver around this issue with
> something that goes all the way back through -stable to the very 1st
> upstream kernel supporting mlx5 EN --- the operational link doesn't go
> down when instructed by the admin and this is an entry level
> requirement from Ethernet of things (such as NIC and Switch ports).
Well, this feature requires updating mlx5_ifc, which was done in
earlier patch which added disable_link_up[0x1] bit,
I think it is doable, but it will introduce a conflict that Dave might
need to solve by not taking this bit from the patch I will send to net
if we decide to do so,
are you saying that i need to drop this patch and submit it to net ?
^ permalink raw reply
* Re: [PATCH net-next 12/12] net/mlx5e: Disable link up on INIT HCA command
From: Or Gerlitz @ 2016-04-23 21:28 UTC (permalink / raw)
To: Saeed Mahameed
Cc: Ido Schimmel, Saeed Mahameed, David S. Miller, Linux Netdev List,
Or Gerlitz, Tal Alon, Eran Ben Elisha, Eugenia Emantayev,
Jiri Pirko, Elad Raz
In-Reply-To: <CALzJLG8Jo5sk=CiHAUDF43RZDGQ1LKRbZftYDpzsO3QJsWx-uA@mail.gmail.com>
On Sun, Apr 24, 2016 at 12:24 AM, Saeed Mahameed
<saeedm@dev.mellanox.co.il> wrote:
> On Sat, Apr 23, 2016 at 11:28 PM, Or Gerlitz <gerlitz.or@gmail.com> wrote:
>> On Sat, Apr 23, 2016 at 11:21 PM, Saeed Mahameed
>> <saeedm@dev.mellanox.co.il> wrote:
>>> On Sat, Apr 23, 2016 at 7:00 PM, Ido Schimmel <idosch@mellanox.com> wrote:
>>
>>>> Also, why is this directed at net-next?
>>
>>> it is kind of new behavior, and not a bug fix.
>>
>> Saeed,
>>
>> We should be aiming to patch the driver around this issue with
>> something that goes all the way back through -stable to the very 1st
>> upstream kernel supporting mlx5 EN --- the operational link doesn't go
>> down when instructed by the admin and this is an entry level
>> requirement from Ethernet of things (such as NIC and Switch ports).
>
> Well, this feature requires updating mlx5_ifc, which was done in
> earlier patch which added disable_link_up[0x1] bit,
> I think it is doable, but it will introduce a conflict that Dave might
> need to solve by not taking this bit from the patch I will send to net
> if we decide to do so,
> are you saying that i need to drop this patch and submit it to net ?
net-next is rebased over net and when needed conflicts are solved. Do
the right patch for net and we will take it from there. Please make
sure your patch/es meet the -stable criteria so they can be pushed
there as well.
Or.
^ permalink raw reply
* [PATCH net-next 0/2] net: ethernet: enc28j60: small improvements
From: Michael Heimpold @ 2016-04-23 21:43 UTC (permalink / raw)
To: Jonathan Cameron, Andrew F . Davis, Mark Brown, netdev,
Claudio Lanconelli
Cc: Michael Heimpold
This series of two patches adds the following improvements to the driver:
1) Rework the central SPI read function so that it is compatible with
SPI masters which only support half duplex transfers.
2) Add a device tree binding for the driver.
Michael Heimpold (2):
net: ethernet: enc28j60: support half-duplex SPI controllers
net: ethernet: enc28j60: add device tree support
.../devicetree/bindings/net/microchip-enc28j60.txt | 49 ++++++++++++++++++++++
drivers/net/ethernet/microchip/enc28j60.c | 27 +++++++++---
2 files changed, 70 insertions(+), 6 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/microchip-enc28j60.txt
--
2.5.0
^ permalink raw reply
* [PATCH net-next 1/2] net: ethernet: enc28j60: support half-duplex SPI controllers
From: Michael Heimpold @ 2016-04-23 21:43 UTC (permalink / raw)
To: Jonathan Cameron, Andrew F . Davis, Mark Brown, netdev,
Claudio Lanconelli
Cc: Michael Heimpold
In-Reply-To: <1461447800-11381-1-git-send-email-mhei@heimpold.de>
The current spi_read_buf function fails on SPI host masters which
are only half-duplex capable. Splitting the Tx and Rx part solves
this issue.
Tested on Raspberry Pi (full duplex) and I2SE Duckbill (half duplex).
Signed-off-by: Michael Heimpold <mhei@heimpold.de>
---
drivers/net/ethernet/microchip/enc28j60.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/microchip/enc28j60.c b/drivers/net/ethernet/microchip/enc28j60.c
index 86ea17e..b723622 100644
--- a/drivers/net/ethernet/microchip/enc28j60.c
+++ b/drivers/net/ethernet/microchip/enc28j60.c
@@ -89,22 +89,26 @@ spi_read_buf(struct enc28j60_net *priv, int len, u8 *data)
{
u8 *rx_buf = priv->spi_transfer_buf + 4;
u8 *tx_buf = priv->spi_transfer_buf;
- struct spi_transfer t = {
+ struct spi_transfer tx = {
.tx_buf = tx_buf,
+ .len = SPI_OPLEN,
+ };
+ struct spi_transfer rx = {
.rx_buf = rx_buf,
- .len = SPI_OPLEN + len,
+ .len = len,
};
struct spi_message msg;
int ret;
tx_buf[0] = ENC28J60_READ_BUF_MEM;
- tx_buf[1] = tx_buf[2] = tx_buf[3] = 0; /* don't care */
spi_message_init(&msg);
- spi_message_add_tail(&t, &msg);
+ spi_message_add_tail(&tx, &msg);
+ spi_message_add_tail(&rx, &msg);
+
ret = spi_sync(priv->spi, &msg);
if (ret == 0) {
- memcpy(data, &rx_buf[SPI_OPLEN], len);
+ memcpy(data, rx_buf, len);
ret = msg.status;
}
if (ret && netif_msg_drv(priv))
--
2.5.0
^ permalink raw reply related
* [PATCH net-next 2/2] net: ethernet: enc28j60: add device tree support
From: Michael Heimpold @ 2016-04-23 21:43 UTC (permalink / raw)
To: Jonathan Cameron, Andrew F . Davis, Mark Brown, netdev,
devicetree, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
Kumar Gala, Claudio Lanconelli
Cc: Michael Heimpold
In-Reply-To: <1461447800-11381-1-git-send-email-mhei@heimpold.de>
The following patch adds the required match table for device tree support
(and while at, fix the indent).
Also add the corresponding binding documentation file.
Signed-off-by: Michael Heimpold <mhei@heimpold.de>
---
.../devicetree/bindings/net/microchip-enc28j60.txt | 49 ++++++++++++++++++++++
drivers/net/ethernet/microchip/enc28j60.c | 13 +++++-
2 files changed, 61 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/net/microchip-enc28j60.txt
diff --git a/Documentation/devicetree/bindings/net/microchip-enc28j60.txt b/Documentation/devicetree/bindings/net/microchip-enc28j60.txt
new file mode 100644
index 0000000..c472427
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/microchip-enc28j60.txt
@@ -0,0 +1,49 @@
+* Microchip ENC28J60
+
+This is a standalone 10 MBit ethernet controller with SPI interface.
+
+For each device connected to a SPI bus, define a child node within
+the SPI master node.
+
+Required properties:
+- compatible: Should be "microchip,enc28j60"
+- reg: Specify the SPI chip select the ENC28J60 is wired to
+- interrupts: Specify the interrupt and interrupt type (usually falling edge)
+
+Optional properties:
+- interrupt-parent: Specify the pHandle of the source interrupt
+- spi-max-frequency: Maximum frequency of the SPI bus when accessing the ENC28J60.
+ According to the ENC28J80 datasheet, the chip allows a maximum of 20 MHz, however,
+ board designs may need to limit this value.
+
+
+Example (for NXP i.MX28 with pin control stuff for GPIO irq):
+
+ ssp2: ssp@80014000 {
+ compatible = "fsl,imx28-spi";
+ pinctrl-names = "default";
+ pinctrl-0 = <&spi2_pins_b &spi2_sck_cfg>;
+ status = "okay";
+
+ enc28j60: ethernet@0 {
+ compatible = "microchip,enc28j60";
+ pinctrl-names = "default";
+ pinctrl-0 = <&enc28j60_pins>;
+ reg = <0>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
+ spi-max-frequency = <12000000>;
+ };
+ };
+
+ pinctrl@80018000 {
+ enc28j60_pins: enc28j60_pins@0 {
+ reg = <0>;
+ fsl,pinmux-ids = <
+ MX28_PAD_AUART0_RTS__GPIO_3_3 /* Interrupt */
+ >;
+ fsl,drive-strength = <MXS_DRIVE_4mA>;
+ fsl,voltage = <MXS_VOLTAGE_HIGH>;
+ fsl,pull-up = <MXS_PULL_DISABLE>;
+ };
+ };
diff --git a/drivers/net/ethernet/microchip/enc28j60.c b/drivers/net/ethernet/microchip/enc28j60.c
index b723622..49635d7 100644
--- a/drivers/net/ethernet/microchip/enc28j60.c
+++ b/drivers/net/ethernet/microchip/enc28j60.c
@@ -1634,9 +1634,20 @@ static int enc28j60_remove(struct spi_device *spi)
return 0;
}
+#ifdef CONFIG_OF
+static const struct of_device_id enc28j60_dt_ids[] = {
+ { .compatible = "microchip,enc28j60" },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, enc28j60_dt_ids);
+#else
+#define enc28j60_dt_ids NULL
+#endif
+
static struct spi_driver enc28j60_driver = {
.driver = {
- .name = DRV_NAME,
+ .name = DRV_NAME,
+ .of_match_table = enc28j60_dt_ids,
},
.probe = enc28j60_probe,
.remove = enc28j60_remove,
--
2.5.0
^ permalink raw reply related
* [PATCH net-next] macvlan: fix failure during registration v3
From: Francesco Ruggeri @ 2016-04-23 22:03 UTC (permalink / raw)
To: netdev
Cc: Francesco Ruggeri, Eric W. Biederman, David S. Miller,
Mahesh Bandewar
If macvlan_common_newlink fails in register_netdevice after macvlan_init
then it decrements port->count twice, first in macvlan_uninit (from
register_netdevice or rollback_registered) and then again in
macvlan_common_newlink.
A similar problem may exist in the ipvlan driver.
This patch consolidates modifications to port->count into macvlan_init
and macvlan_uninit (thanks to Eric Biederman for suggesting this approach).
v3: remove macvtap specific bits.
Signed-off-by: Francesco Ruggeri <fruggeri@arista.com>
---
drivers/net/macvlan.c | 10 ++++------
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index 2bcf1f3..cb01023 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -795,6 +795,7 @@ static int macvlan_init(struct net_device *dev)
{
struct macvlan_dev *vlan = netdev_priv(dev);
const struct net_device *lowerdev = vlan->lowerdev;
+ struct macvlan_port *port = vlan->port;
dev->state = (dev->state & ~MACVLAN_STATE_MASK) |
(lowerdev->state & MACVLAN_STATE_MASK);
@@ -812,6 +813,8 @@ static int macvlan_init(struct net_device *dev)
if (!vlan->pcpu_stats)
return -ENOMEM;
+ port->count += 1;
+
return 0;
}
@@ -1312,10 +1315,9 @@ int macvlan_common_newlink(struct net *src_net, struct net_device *dev,
return err;
}
- port->count += 1;
err = register_netdevice(dev);
if (err < 0)
- goto destroy_port;
+ return err;
dev->priv_flags |= IFF_MACVLAN;
err = netdev_upper_dev_link(lowerdev, dev);
@@ -1330,10 +1332,6 @@ int macvlan_common_newlink(struct net *src_net, struct net_device *dev,
unregister_netdev:
unregister_netdevice(dev);
-destroy_port:
- port->count -= 1;
- if (!port->count)
- macvlan_port_destroy(lowerdev);
return err;
}
--
1.8.1.4
^ permalink raw reply related
* [PATCH net-next] macvtap: check minor when unregistering
From: Francesco Ruggeri @ 2016-04-23 22:04 UTC (permalink / raw)
To: netdev; +Cc: Francesco Ruggeri, Eric W. Biederman, David S. Miller
macvtap_device_event(NETDEV_UNREGISTER) should check vlan->minor to
determine if it is being invoked in the context of a macvtap_newlink
that failed, for example in this code sequence:
macvtap_newlink
macvlan_common_newlink
register_netdevice
call_netdevice_notifiers(NETDEV_REGISTER, dev)
macvtap_device_event(NETDEV_REGISTER)
<fail here, vlan->minor = 0>
rollback_registered(dev);
rollback_registered_many
call_netdevice_notifiers(NETDEV_UNREGISTER, dev);
macvtap_device_event(NETDEV_UNREGISTER)
<nothing to clean up here>
Signed-off-by: Francesco Ruggeri <fruggeri@arista.com>
---
drivers/net/macvtap.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 95394ed..74cb15a 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -1303,6 +1303,9 @@ static int macvtap_device_event(struct notifier_block *unused,
}
break;
case NETDEV_UNREGISTER:
+ /* vlan->minor == 0 if NETDEV_REGISTER above failed */
+ if (vlan->minor == 0)
+ break;
devt = MKDEV(MAJOR(macvtap_major), vlan->minor);
device_destroy(macvtap_class, devt);
macvtap_free_minor(vlan);
--
1.8.1.4
^ permalink raw reply related
* Re: [PATCH net-next 2/2] net: ethernet: enc28j60: add device tree support
From: Arnd Bergmann @ 2016-04-23 22:20 UTC (permalink / raw)
To: Michael Heimpold
Cc: Jonathan Cameron, Andrew F . Davis, Mark Brown, netdev,
devicetree, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
Kumar Gala, Claudio Lanconelli
In-Reply-To: <1461447800-11381-3-git-send-email-mhei@heimpold.de>
On Saturday 23 April 2016 23:43:20 Michael Heimpold wrote:
> diff --git a/drivers/net/ethernet/microchip/enc28j60.c b/drivers/net/ethernet/microchip/enc28j60.c
> index b723622..49635d7 100644
> --- a/drivers/net/ethernet/microchip/enc28j60.c
> +++ b/drivers/net/ethernet/microchip/enc28j60.c
> @@ -1634,9 +1634,20 @@ static int enc28j60_remove(struct spi_device *spi)
> return 0;
> }
>
> +#ifdef CONFIG_OF
> +static const struct of_device_id enc28j60_dt_ids[] = {
> + { .compatible = "microchip,enc28j60" },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, enc28j60_dt_ids);
> +#else
> +#define enc28j60_dt_ids NULL
> +#endif
> +
> static struct spi_driver enc28j60_driver = {
> .driver = {
> - .name = DRV_NAME,
> + .name = DRV_NAME,
> + .of_match_table = enc28j60_dt_ids,
> },
> .probe = enc28j60_probe,
> .remove = enc28j60_remove,
> --
>
You probably also want to add support for calling of_get_mac_address()
here, to allow giving the device a fixed address from the boot loader.
I think you can drop the #ifdef and just define the device table
unconditionally.
Arnd
^ permalink raw reply
* Re: [PATCH net-next 12/12] net/mlx5e: Disable link up on INIT HCA command
From: Ido Schimmel @ 2016-04-23 22:03 UTC (permalink / raw)
To: Saeed Mahameed
Cc: Saeed Mahameed, David S. Miller, Linux Netdev List, Or Gerlitz,
Tal Alon, Eran Ben Elisha, Eugenia Emantayev, Jiri Pirko, eladr
In-Reply-To: <CALzJLG-AWFHnba=ysCAQLqCjFHo3L-sQTeW+NbpMg-X6PRtRPQ@mail.gmail.com>
Sat, Apr 23, 2016 at 11:21:45PM IDT, saeedm@dev.mellanox.co.il wrote:
>On Sat, Apr 23, 2016 at 7:00 PM, Ido Schimmel <idosch@mellanox.com> wrote:
>> mutt suggests I sent you the following patches a while ago:
>>
>> net/mlx5e: Set port administrative status in ndo_{open, close}
>> net/mlx5e: Initialize port administrative status to down
>>
>> So I'm curious as to why you didn't follow up on them and instead came
>> up with this patch.
>>
>> When I initially debugged this I pointed you to the fact that the
>> firmware also needs to be patched, as setting the administrative status
>> down via PAOS doesn't really do anything. The operational status will
>> remain up. I just tested this patchset with the latest release firmware
>> (12.14.2036) and I'm bumping into the same problem.
>>
>
>Hi Ido,
>
>I do remember that patch, and back then i told you that your patch is
>not cooked enough and that we were working on a solution:
>
>1. you need to negotiate with the FW on if the FW can give up port
>ownership to SW, you can find that in handle_hca_cap,
>MLX5_CAP_GEN_MAX(dev, disable_link_up).
Yea, I don't think that part was available back then? I just directly
set a value in firmware memory hoping it would be the default in the
next version following my report.
>2. you need to configure the FW to give up port ownership via NVconfig
>(mlxconfig tool) i think it is PORT_OWNER bit, Eran can elaborate
>more if needed.
I'll check that tomorrow morning and report.
>3.1 and 2 are required for mlx5_set_port_admin_status to take effect,
>otherwise it is a NOOP.
>
>Eran tested this patch and it works for him, maybe you missed step 2.
>Step 2 will not be required in future FW (it will be the FW default).
Great!
>Other than this patch, nothing more is required for driver to assume
>ownership on port's link status.
>
>> Until this is properly fixed the mlx5 driver is blacklisted in our test:
>> https://github.com/jpirko/lnst/blob/master/recipes/switchdev/basic-001-links.py#L19
>>
>> Also, why is this directed at net-next?
>>
>
>it is kind of new behavior, and not a bug fix.
>
>>> drivers/infiniband/hw/mlx5/main.c | 11 +++++++++++
>>> drivers/infiniband/hw/mlx5/mlx5_ib.h | 5 +++++
>>> drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c | 4 ++--
>>> .../net/ethernet/mellanox/mlx5/core/en_ethtool.c | 4 ++--
>>> drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 4 ++++
>>> drivers/net/ethernet/mellanox/mlx5/core/main.c | 4 ++++
>>> drivers/net/ethernet/mellanox/mlx5/core/port.c | 5 +++--
>>> include/linux/mlx5/port.h | 3 ++-
>>> 8 files changed, 33 insertions(+), 7 deletions(-)
>>>
>>
>> [...]
>>
>>>diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c b/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c
>>>index b2db180..f083797 100644
>>>--- a/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c
>>>+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c
>>>@@ -202,12 +202,12 @@ static int mlx5e_dcbnl_ieee_setpfc(struct net_device *dev,
>>>
>>> mlx5_query_port_admin_status(mdev, &ps);
>>> if (ps == MLX5_PORT_UP)
>>>- mlx5_set_port_admin_status(mdev, MLX5_PORT_DOWN);
>>>+ mlx5_set_port_admin_status(mdev, MLX5_PORT_DOWN, 1);
>>
>> Why is this needed? The link doesn't need to go through training when
>> setting PFC. It's only needed for PAUSE frames when auto-negotiation is
>> on, but you don't support that anyway.
>>
>> Thanks.
>>
>
>The code was there before this patch, only the function prototype was changed.
>Maybe you have a valid point here, but this need to be fixed in a
>different patch, it has nothing to do with this one.
>Eran and Team please check this on Sunday, I found nothing re this
>matter in PRM.
See PFCC register:
"Setting pfctx / pfcrx when the link is up takes effect immediately."
Thanks.
^ permalink raw reply
* net merged into net-next
From: David Miller @ 2016-04-24 0:12 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
Eric, please double check my merge work for net/ipv4/udp.c
In net we fixed a soreuseport bug that added a hlist_nulls_add_tail_rcu()
call to net/ipv4/udp.c
And in net-next you converted UDP sockets away from nulls lists.
Therefore I had to add a hlist_add_tail_rcu() implementation to
linux/rculist.h and use it in net/ipv4/udp.c
Please make sure this is fine and will work safely.
Thanks!
^ permalink raw reply
* Re: [PATCH net-next 0/9] netlink: align attributes when needed (patchset #1)
From: David Miller @ 2016-04-24 0:13 UTC (permalink / raw)
To: nicolas.dichtel-pdR9zngts4EAvxtiuMwx3w
Cc: dev-yBygre7rU0TnMu66kgdUjQ,
steffen.klassert-opNxpl+3fjRBDgjK7y7TUQ,
herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q,
aar-bIcnvbaLZ9MEGnE8C9+IrQ, netdev-u79uwXL29TY76Z2rM5mHXA,
bsingharora-Re5JQEeQqe8AvxtiuMwx3w,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
jmorris-gx6/JNMH7DfYtjvyW6yDsg, yoshfuji-VfPWfsRibaP+Ru+s062T9g,
netfilter-devel-u79uwXL29TY76Z2rM5mHXA,
kadlec-K40Dz/62t/MgiyqX0sVFJYdd74u8MsAO,
kuznet-v/Mj1YrvjDBInbfyfbPRSQ, linux-wpan-u79uwXL29TY76Z2rM5mHXA,
kaber-dcUjhNyLwpNeoWH0uzbU5w, pablo-Cap9r6Oaw4JrovVCs/uTlw
In-Reply-To: <1461339084-3849-1-git-send-email-nicolas.dichtel-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Fri, 22 Apr 2016 17:31:15 +0200
> This is the continuation of the work done to align netlink attributes
> when these attributes contain some 64-bit fields.
>
> David, if the third patch is too big (or maybe the series), I can split it.
> Just tell me what you prefer.
This looks excellent, series applied, thanks!
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* Re: [PATCH net] net/mlx4_en: fix spurious timestamping callbacks
From: Eric Dumazet @ 2016-04-24 0:55 UTC (permalink / raw)
To: Or Gerlitz; +Cc: David Miller, netdev, Eugenia Emantayev, Eran Ben Elisha
In-Reply-To: <CAJ3xEMg3HwbZG6qh5=ydaUesQX_goRSD6H_LowsEuW46TVDnbA@mail.gmail.com>
On Sat, 2016-04-23 at 23:23 +0300, Or Gerlitz wrote:
> On Sat, Apr 23, 2016 at 9:35 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > From: Eric Dumazet <edumazet@google.com>
> >
> > When multiple skb are TX-completed in a row, we might incorrectly keep
> > a timestamp of a prior skb and cause extra work.
> >
> > Fixes: ec693d47010e8 ("net/mlx4_en: Add HW timestamping (TS) support")
> > Signed-off-by: Eric Dumazet <edumazet@google.com>
> > Willem de Bruijn <willemb@google.com>
>
> Eric, was that supposed to be Reported-by: or Signed-off-by: ...
This was meant to be.
Cc: Willem de Bruijn <willemb@google.com>
Willem was CC on the original bug at Google (Google-Bug-Id: 28356763 )
Thanks.
^ permalink raw reply
* Re: net merged into net-next
From: Eric Dumazet @ 2016-04-24 1:39 UTC (permalink / raw)
To: David Miller, Craig Gallek; +Cc: netdev
In-Reply-To: <20160423.201230.364025148300253838.davem@davemloft.net>
On Sat, 2016-04-23 at 20:12 -0400, David Miller wrote:
> Eric, please double check my merge work for net/ipv4/udp.c
>
> In net we fixed a soreuseport bug that added a hlist_nulls_add_tail_rcu()
> call to net/ipv4/udp.c
>
> And in net-next you converted UDP sockets away from nulls lists.
>
> Therefore I had to add a hlist_add_tail_rcu() implementation to
> linux/rculist.h and use it in net/ipv4/udp.c
>
> Please make sure this is fine and will work safely.
>
> Thanks!
Looks fine to me, thanks David
Craig, please have a look ?
( commit 1602f49b58abcb0d34a5f0a29d68e7c1769547aa in net-next)
^ permalink raw reply
* Re: [PATCH 00/23] Netfilter updates for net-next
From: David Miller @ 2016-04-24 4:26 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <1461332394-3994-1-git-send-email-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Fri, 22 Apr 2016 15:39:31 +0200
> The following patchset contains Netfilter updates for your net-next
> tree, mostly from Florian Westphal to sort out the lack of sufficient
> validation in x_tables and connlabel preparation patches to add
> nf_tables support. They are:
...
> You can pull these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf-next.git
Pulled, thanks a lot Pablo!
^ permalink raw reply
* smc911 vs smsc911
From: Ran Shalit @ 2016-04-24 5:25 UTC (permalink / raw)
To: netdev
Hello,
Does anyone can say what's the difference between smc911 and smsc911 ?
On reading the first comments in each file it seems that there is
overlapping between them:
smc911x.c
========
* This is a driver for SMSC's LAN911{5,6,7,8} single-chip Ethernet devices.
smsc911x.c
===========
* Supported devices:
* LAN9115, LAN9116, LAN9117, LAN9118
* LAN9215, LAN9216, LAN9217, LAN9218
* LAN9210, LAN9211
* LAN9220, LAN9221
* LAN89218
*
*/
Regards,
Ran
^ permalink raw reply
* VRF_DEVICE integration plan
From: Elluru, Krishna Mohan @ 2016-04-24 4:07 UTC (permalink / raw)
To: netdev@vger.kernel.org
HI Netdev team,
Greetings. We have been monitoring the vrf device approach for l3 isolation from cumulus networks and we are currently interested in validating it. We have following questions on them and hoping to get answers from you/concerned team.
1. As per the linux documentation, there are known limits on if_index lookup, as the incoming if_index is changed to vrf_device index and thus an application receiving this packet will perceive this as a vrf_device packet, than right if_index. I saw you mentioned about a special flag to identify the origin, but didn't see the same in the latest linux 4.4.2 version code. Is there a patch expected for it?
2. What are the future additions planned for this approach? Are there any ipv4 and ipv6 known bugs with vrf_device model?
3. It has been said in the documentation that, with addition of cgroup functionality for vrf device, with net_admin capabilities, we should be able to add an interface to vrf_device, currently it is not so. Any timelines on these?
4. Currently the changes are available and portable from 4.3.x onwards. Is there a plan to port them to previous kernel versions?
5. Is there a possibility of enabling secondary level lookup, to give a leak functionality to parent route table from device local route table? I tested with veth pair, configured one as default gateway, it is possible to forward traffic b/w the interfaces, looking for cleaner method.
6. With "VRF Device" in place, please confirm if there are any plans to add VRF support for applications like
1. Ping
2. Traceroute
3. DNS-Client [glibc]
In case of DNS-Client, most of the name resolution APIs will have to consider the VRF to do the lookup in and the way the domain-name/name-server configuration is stored.
Please revert back, if you need more clarification on the questions.
Thanks in Advance
Krishna Mohan
^ permalink raw reply
* [PATCH 03/21] io-mapping: Specify mapping size for io_mapping_map_wc()
From: Chris Wilson @ 2016-04-24 7:18 UTC (permalink / raw)
To: intel-gfx
Cc: Tvrtko Ursulin, netdev, Yishai Hadas, linux-kernel,
Peter Zijlstra (Intel), Luis R . Rodriguez, dri-devel, linux-rdma,
Daniel Vetter, Dan Williams, Ingo Molnar, David Hildenbrand
In-Reply-To: <1461482332-21975-1-git-send-email-chris@chris-wilson.co.uk>
The ioremap() hidden behind the io_mapping_map_wc() convenience helper
can be used for remapping multiple pages. Extend the helper so that
future callers can use it for larger ranges.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Yishai Hadas <yishaih@mellanox.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Cc: David Hildenbrand <dahi@linux.vnet.ibm.com>
Cc: Luis R. Rodriguez <mcgrof@kernel.org>
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: netdev@vger.kernel.org
Cc: linux-rdma@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
drivers/gpu/drm/i915/intel_overlay.c | 3 ++-
drivers/net/ethernet/mellanox/mlx4/pd.c | 4 +++-
include/linux/io-mapping.h | 10 +++++++---
3 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_overlay.c b/drivers/gpu/drm/i915/intel_overlay.c
index 9746b9841c13..0d5a376878d3 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@ -198,7 +198,8 @@ intel_overlay_map_regs(struct intel_overlay *overlay)
regs = (struct overlay_registers __iomem *)overlay->reg_bo->phys_handle->vaddr;
else
regs = io_mapping_map_wc(ggtt->mappable,
- overlay->flip_addr);
+ overlay->flip_addr,
+ PAGE_SIZE);
return regs;
}
diff --git a/drivers/net/ethernet/mellanox/mlx4/pd.c b/drivers/net/ethernet/mellanox/mlx4/pd.c
index b3cc3ab63799..6fc156a3918d 100644
--- a/drivers/net/ethernet/mellanox/mlx4/pd.c
+++ b/drivers/net/ethernet/mellanox/mlx4/pd.c
@@ -205,7 +205,9 @@ int mlx4_bf_alloc(struct mlx4_dev *dev, struct mlx4_bf *bf, int node)
goto free_uar;
}
- uar->bf_map = io_mapping_map_wc(priv->bf_mapping, uar->index << PAGE_SHIFT);
+ uar->bf_map = io_mapping_map_wc(priv->bf_mapping,
+ uar->index << PAGE_SHIFT,
+ PAGE_SIZE);
if (!uar->bf_map) {
err = -ENOMEM;
goto unamp_uar;
diff --git a/include/linux/io-mapping.h b/include/linux/io-mapping.h
index e399029b68c5..645ad06b5d52 100644
--- a/include/linux/io-mapping.h
+++ b/include/linux/io-mapping.h
@@ -100,14 +100,16 @@ io_mapping_unmap_atomic(void __iomem *vaddr)
}
static inline void __iomem *
-io_mapping_map_wc(struct io_mapping *mapping, unsigned long offset)
+io_mapping_map_wc(struct io_mapping *mapping,
+ unsigned long offset,
+ unsigned long size)
{
resource_size_t phys_addr;
BUG_ON(offset >= mapping->size);
phys_addr = mapping->base + offset;
- return ioremap_wc(phys_addr, PAGE_SIZE);
+ return ioremap_wc(phys_addr, size);
}
static inline void
@@ -155,7 +157,9 @@ io_mapping_unmap_atomic(void __iomem *vaddr)
/* Non-atomic map/unmap */
static inline void __iomem *
-io_mapping_map_wc(struct io_mapping *mapping, unsigned long offset)
+io_mapping_map_wc(struct io_mapping *mapping,
+ unsigned long offset,
+ unsigned long size)
{
return ((char __force __iomem *) mapping) + offset;
}
--
2.8.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* [PATCH v2 03/21] io-mapping: Specify mapping size for io_mapping_map_wc()
From: Chris Wilson @ 2016-04-24 7:31 UTC (permalink / raw)
To: intel-gfx
Cc: Tvrtko Ursulin, netdev, Yishai Hadas, linux-kernel,
Peter Zijlstra (Intel), Luis R . Rodriguez, dri-devel, linux-rdma,
Daniel Vetter, Dan Williams, Ingo Molnar, David Hildenbrand
In-Reply-To: <1461483101-10618-1-git-send-email-chris@chris-wilson.co.uk>
The ioremap() hidden behind the io_mapping_map_wc() convenience helper
can be used for remapping multiple pages. Extend the helper so that
future callers can use it for larger ranges.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Yishai Hadas <yishaih@mellanox.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: "Peter Zijlstra (Intel)" <peterz@infradead.org>
Cc: David Hildenbrand <dahi@linux.vnet.ibm.com>
Cc: Luis R. Rodriguez <mcgrof@kernel.org>
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: netdev@vger.kernel.org
Cc: linux-rdma@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Luis R. Rodriguez <mcgrof@kernel.org>
---
drivers/gpu/drm/i915/intel_overlay.c | 3 ++-
drivers/net/ethernet/mellanox/mlx4/pd.c | 4 +++-
include/linux/io-mapping.h | 10 +++++++---
3 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_overlay.c b/drivers/gpu/drm/i915/intel_overlay.c
index 9746b9841c13..0d5a376878d3 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@ -198,7 +198,8 @@ intel_overlay_map_regs(struct intel_overlay *overlay)
regs = (struct overlay_registers __iomem *)overlay->reg_bo->phys_handle->vaddr;
else
regs = io_mapping_map_wc(ggtt->mappable,
- overlay->flip_addr);
+ overlay->flip_addr,
+ PAGE_SIZE);
return regs;
}
diff --git a/drivers/net/ethernet/mellanox/mlx4/pd.c b/drivers/net/ethernet/mellanox/mlx4/pd.c
index b3cc3ab63799..6fc156a3918d 100644
--- a/drivers/net/ethernet/mellanox/mlx4/pd.c
+++ b/drivers/net/ethernet/mellanox/mlx4/pd.c
@@ -205,7 +205,9 @@ int mlx4_bf_alloc(struct mlx4_dev *dev, struct mlx4_bf *bf, int node)
goto free_uar;
}
- uar->bf_map = io_mapping_map_wc(priv->bf_mapping, uar->index << PAGE_SHIFT);
+ uar->bf_map = io_mapping_map_wc(priv->bf_mapping,
+ uar->index << PAGE_SHIFT,
+ PAGE_SIZE);
if (!uar->bf_map) {
err = -ENOMEM;
goto unamp_uar;
diff --git a/include/linux/io-mapping.h b/include/linux/io-mapping.h
index e399029b68c5..645ad06b5d52 100644
--- a/include/linux/io-mapping.h
+++ b/include/linux/io-mapping.h
@@ -100,14 +100,16 @@ io_mapping_unmap_atomic(void __iomem *vaddr)
}
static inline void __iomem *
-io_mapping_map_wc(struct io_mapping *mapping, unsigned long offset)
+io_mapping_map_wc(struct io_mapping *mapping,
+ unsigned long offset,
+ unsigned long size)
{
resource_size_t phys_addr;
BUG_ON(offset >= mapping->size);
phys_addr = mapping->base + offset;
- return ioremap_wc(phys_addr, PAGE_SIZE);
+ return ioremap_wc(phys_addr, size);
}
static inline void
@@ -155,7 +157,9 @@ io_mapping_unmap_atomic(void __iomem *vaddr)
/* Non-atomic map/unmap */
static inline void __iomem *
-io_mapping_map_wc(struct io_mapping *mapping, unsigned long offset)
+io_mapping_map_wc(struct io_mapping *mapping,
+ unsigned long offset,
+ unsigned long size)
{
return ((char __force __iomem *) mapping) + offset;
}
--
2.8.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* Re: [PATCH v5 00/21] Add HiSilicon RoCE driver
From: Leon Romanovsky @ 2016-04-24 7:44 UTC (permalink / raw)
To: Lijun Ou
Cc: dledford, sean.hefty, hal.rosenstock, davem, jeffrey.t.kirsher,
jiri, ogerlitz, linuxarm, linux-rdma, linux-kernel, netdev,
gongyangming, xiaokun, tangchaofei, haifeng.wei, yisen.zhuang,
yankejian, lisheng011, charles.chenxin
In-Reply-To: <1461407219-72027-1-git-send-email-oulijun@huawei.com>
[-- Attachment #1: Type: text/plain, Size: 909 bytes --]
On Sat, Apr 23, 2016 at 06:26:38PM +0800, Lijun Ou wrote:
> The HiSilicon Network Substem is a long term evolution IP which is
> supposed to be used in HiSilicon ICT SoCs. HNS (HiSilicon Network
> Sybsystem) also has a hardware support of performing RDMA with
> RoCEE.
> The driver for HiSilicon RoCEE(RoCE Engine) is a platform driver and will
> support mulitple versions of SOCs in future. This version of driver is
> meant to support Hip06 SoC (which confirms to RoCEEv1 hardware specifications).
>
> Changes v5 -> v4:
v4 -> v5
> 1. redesign the patchset for RoCE modules in order to split the huge
> patch into small patches.
Thanks,
I may admit that I didn't look on the patches yet, however two things
already spotted my attention:
1. Please fix Signed-off-by signatures to include First name, Last name
and email address.
2. Please run spelling checker on all your patches.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v5 09/21] IB/hns: Add hca support
From: Leon Romanovsky @ 2016-04-24 7:54 UTC (permalink / raw)
To: Lijun Ou
Cc: dledford, sean.hefty, hal.rosenstock, davem, jeffrey.t.kirsher,
jiri, ogerlitz, linuxarm, linux-rdma, linux-kernel, netdev,
gongyangming, xiaokun, tangchaofei, haifeng.wei, yisen.zhuang,
yankejian, lisheng011, charles.chenxin
In-Reply-To: <1461407219-72027-10-git-send-email-oulijun@huawei.com>
[-- Attachment #1: Type: text/plain, Size: 2645 bytes --]
On Sat, Apr 23, 2016 at 06:26:47PM +0800, Lijun Ou wrote:
> This patch mainly setup hca for RoCE. it will do a series of
> initial works as follows:
> 1. init uar table, allocate uar resource
> 2. init pd table
> 3. init cq table
> 4. init mr table
> 5. init qp table
>
> Signed-off-by: Lijun Ou <oulijun@huawei.com>
> Signed-off-by: Wei Hu(Xavier) <xavier.huwei@huawei.com>
> ---
> drivers/infiniband/hw/hns/hns_roce_alloc.c | 104 ++++++++++++++++
> drivers/infiniband/hw/hns/hns_roce_cq.c | 25 ++++
> drivers/infiniband/hw/hns/hns_roce_device.h | 69 ++++++++++
> drivers/infiniband/hw/hns/hns_roce_eq.c | 1 -
> drivers/infiniband/hw/hns/hns_roce_icm.c | 88 +++++++++++++
> drivers/infiniband/hw/hns/hns_roce_icm.h | 9 ++
> drivers/infiniband/hw/hns/hns_roce_main.c | 79 ++++++++++++
> drivers/infiniband/hw/hns/hns_roce_mr.c | 187 ++++++++++++++++++++++++++++
> drivers/infiniband/hw/hns/hns_roce_pd.c | 65 ++++++++++
> drivers/infiniband/hw/hns/hns_roce_qp.c | 30 +++++
> 10 files changed, 656 insertions(+), 1 deletion(-)
> create mode 100644 drivers/infiniband/hw/hns/hns_roce_alloc.c
> create mode 100644 drivers/infiniband/hw/hns/hns_roce_mr.c
> create mode 100644 drivers/infiniband/hw/hns/hns_roce_pd.c
>
> diff --git a/drivers/infiniband/hw/hns/hns_roce_alloc.c b/drivers/infiniband/hw/hns/hns_roce_alloc.c
> new file mode 100644
> index 0000000..0c76f1b
> --- /dev/null
> +++ b/drivers/infiniband/hw/hns/hns_roce_alloc.c
> @@ -0,0 +1,104 @@
> +/*
> + * Copyright (c) 2016 Hisilicon Limited.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include <linux/bitmap.h>
> +#include <linux/dma-mapping.h>
> +#include <linux/errno.h>
> +#include <linux/mm.h>
> +#include <linux/slab.h>
> +#include <linux/vmalloc.h>
> +#include "hns_roce_device.h"
> +
> +int hns_roce_bitmap_alloc(struct hns_roce_bitmap *bitmap, u32 *obj)
> +{
> + int ret = 0;
> +
> + spin_lock(&bitmap->lock);
> + *obj = find_next_zero_bit(bitmap->table, bitmap->max, bitmap->last);
> + if (*obj >= bitmap->max) {
> + bitmap->top = (bitmap->top + bitmap->max + bitmap->reserved_top)
> + & bitmap->mask;
> + *obj = find_first_zero_bit(bitmap->table, bitmap->max);
find_first_zero_bit function returns "unsigned long" which may or may
not be equal to u32 on some architectures.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH net] net/mlx4_en: fix spurious timestamping callbacks
From: Eran Ben Elisha @ 2016-04-24 8:24 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Eugenia Emantayev
In-Reply-To: <1461436546.7627.45.camel@edumazet-glaptop3.roam.corp.google.com>
On Sat, Apr 23, 2016 at 9:35 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> When multiple skb are TX-completed in a row, we might incorrectly keep
> a timestamp of a prior skb and cause extra work.
>
> Fixes: ec693d47010e8 ("net/mlx4_en: Add HW timestamping (TS) support")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Willem de Bruijn <willemb@google.com>
Other than the commit message issue raised by Or,
Reviewed-by: Eran Ben Elisha <eranbe@mellanox.com>
^ permalink raw reply
* Re: [PATCH net 1/3] gre: do not assign header_ops in collect metadata mode
From: Jiri Benc @ 2016-04-24 9:31 UTC (permalink / raw)
To: Thomas Graf
Cc: pravin shelar, Linux Kernel Network Developers, Pravin B Shelar,
Simon Horman
In-Reply-To: <20160423014143.GC32327@pox.localdomain>
On Sat, 23 Apr 2016 03:41:43 +0200, Thomas Graf wrote:
> On 04/22/16 at 11:20pm, Jiri Benc wrote:
> > On Fri, 22 Apr 2016 14:04:48 -0700, pravin shelar wrote:
> > > I think we should we return error in case of such configuration rather
> > > than silently ignoring it.
> >
> > I thought about it and I'm not sure. We're not returning an error
> > currently, starting returning it now might be perceived as uAPI
> > breakage.
> >
> > But given it doesn't work at all currently, there are apparently no
> > users yet. I'll wait for more feedback.
>
> As a user, I would probably favour receiving an error for a configuration
> that can't possibly work and was not working before.
Okay, I'll change this in v2. Thanks, Pravin and Thomas.
Jiri
^ permalink raw reply
* Re: [PATCH net 3/3] gre: receive also TEB packets for lwtunnels
From: Jiri Benc @ 2016-04-24 9:38 UTC (permalink / raw)
To: Simon Horman; +Cc: Thomas Graf, netdev, Pravin B Shelar
In-Reply-To: <20160423050912.GA4520@penelope.isobedori.kobe.vergenet.net>
On Sat, 23 Apr 2016 15:09:16 +1000, Simon Horman wrote:
> On Sat, Apr 23, 2016 at 03:49:38AM +0200, Thomas Graf wrote:
> > I may be missing some context. Is anyone using this already or is this
> > preparing the stage for another user? It's not clear to me from the
> > commit message.
>
> Hi Thomas,
>
> I'm not sure what use Jiri may have in mind but I plan to use
> this to allow OvS to support packets without an Ethernet header to
> be received from and sent to a GRE tunnel.
>
> I am reasonably sure there are no existing users.
Yes, that's the main use case as far as I can see. Sorry for not being
clear.
The intention is to support tunnels that can have mixed L2+L3 traffic
over a single lwtunnel interface. VXLAN-GPE already does this, this
patch makes GRE behave identically, while preserving all current GRE
users.
The reason I sent this for net and not net-next is that I wanted to
prevent the situation when we have a kernel released that supports
ipgre lwtunnels but incompletely - i.e., ETH_P_TEB frames are
discarded. But thinking about it more, it's probably non-issue. I'll
retarget this patch for net-next and resend the first two for net.
Thanks,
Jiri
^ 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