Wed, Feb 28, 2024 at 12:04:41PM CET, wangyunj...@huawei.com wrote:
>Hi all:
>
>Now, some drivers support the zero-copy feature of AF_XDP sockets,
>which can significantly reduce CPU utilization for XDP programs.
>
>This patch set allows TUN to also support the AF_XDP Tx zero-copy
>feature. It is
Thu, Feb 01, 2024 at 01:57:16PM CET, john.g.ga...@oracle.com wrote:
>On 31/01/2024 19:24, Jakub Kicinski wrote:
>> On Wed, 31 Jan 2024 10:48:50 + John Garry wrote:
>> > Instead of using UTS_RELEASE, use uts_release, which means that we don't
>> > need to rebuild the code just for the git head
",
>"values": [ {
>"cmode": "runtime",
> "value": false
>} ]
>} ]
>}
>}
>
>Signed-off-by: Oleksandr Mazur
Looks fine.
Reviewed-by: Jiri Pirko
Mon, Jan 25, 2021 at 01:24:27PM CET, oleksandr.ma...@plvision.eu wrote:
>Thu, Jan 21, 2021 at 06:36:05PM CET, k...@kernel.org wrote:
>>On Thu, 21 Jan 2021 14:21:52 +0200 Ido Schimmel wrote:
>>> On Thu, Jan 21, 2021 at 01:29:37PM +0200, Oleksandr Mazur wrote:
>>> > Add new trap action HARD_DROP,
Thu, Jan 21, 2021 at 06:36:05PM CET, k...@kernel.org wrote:
>On Thu, 21 Jan 2021 14:21:52 +0200 Ido Schimmel wrote:
>> On Thu, Jan 21, 2021 at 01:29:37PM +0200, Oleksandr Mazur wrote:
>> > Add new trap action HARD_DROP, which can be used by the
>> > drivers to register traps, where it's impossible
Fri, Jan 08, 2021 at 12:58:13AM CET, ja...@redhat.com wrote:
>On Mon, Dec 28, 2020 at 11:11:45AM +0100, Jiri Pirko wrote:
>> Fri, Dec 18, 2020 at 08:30:33PM CET, ja...@redhat.com wrote:
>> >This comes from an end-user request, where they're running multiple VMs on
>> >h
Fri, Dec 18, 2020 at 08:30:33PM CET, ja...@redhat.com wrote:
>This comes from an end-user request, where they're running multiple VMs on
>hosts with bonded interfaces connected to some interest switch topologies,
>where 802.3ad isn't an option. They're currently running a proprietary
>solution
Mon, Nov 30, 2020 at 02:13:35PM CET, steen.hegel...@microchip.com wrote:
>On 27.11.2020 18:15, Andrew Lunn wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
>> content is safe
>>
>> This is a very large driver, which is going to make it slow to review.
>Hi
Mon, Nov 23, 2020 at 11:28:28AM CET, gcher...@marvell.com wrote:
>Hi Jiri,
>
>> -Original Message-----
>> From: Jiri Pirko
>> Sent: Monday, November 23, 2020 3:52 PM
>> To: George Cherian
>> Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org;
>
Mon, Nov 23, 2020 at 03:49:06AM CET, gcher...@marvell.com wrote:
>
>
>> -Original Message-----
>> From: Jiri Pirko
>> Sent: Saturday, November 21, 2020 7:44 PM
>> To: George Cherian
>> Cc: net...@vger.kernel.org; linux-kernel@vger.kernel.org;
>> k
Sat, Nov 21, 2020 at 05:02:00AM CET, george.cher...@marvell.com wrote:
>Add health reporters for RVU NPA block.
>NPA Health reporters handle following HW event groups
> - GENERAL events
> - ERROR events
> - RAS events
> - RVU event
>An event counter per event is maintained in SW.
>
>Output:
> #
mplement restricted fw_activate on mlx5.
>
>Have the uapi parameter of reload limit ready for future support of
>multiselection.
>
>Signed-off-by: Moshe Shemesh
Reviewed-by: Jiri Pirko
t;stats": {
>"reload": {
>"driver_reinit": 1,
>"fw_activate": 0,
>"fw_activate_no_reset": 0
> },
>"remote_reload": {
>"driver_reinit": 1,
>"fw_activate": 1,
>"fw_activate_no_reset": 0
>}
>}
>}
>}
>}
>
>Signed-off-by: Moshe Shemesh
>Reviewed-by: Jakub Kicinski
Reviewed-by: Jiri Pirko
{
>"stats": {
>"reload": {
> "driver_reinit": 1,
>"fw_activate": 0,
>"fw_activate_no_reset": 0
>}
>}
>}
>}
>}
>
>Signed-off-by: Moshe Shemesh
Reviewed-by: Jiri Pirko
r_reinit
>
>$devlink dev reload pci/:82:00.0 action fw_activate
>reload_actions_performed:
> driver_reinit fw_activate
>
>Signed-off-by: Moshe Shemesh
>Reviewed-by: Jakub Kicinski
>Reviewed-by: Jacob Keller
Reviewed-by: Jiri Pirko
Mon, Oct 05, 2020 at 03:07:12PM CEST, allan.niel...@microchip.com wrote:
>Hi Jiri
>
>On 01.10.2020 14:49, Jiri Pirko wrote:
>> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
>> content is safe
>>
>> Thu, Oct 01, 2020 at 12:30:18PM CEST
Sun, Oct 04, 2020 at 08:42:47AM CEST, mo...@nvidia.com wrote:
>
>On 10/3/2020 10:51 AM, Jiri Pirko wrote:
>> Thu, Oct 01, 2020 at 03:59:06PM CEST, mo...@mellanox.com wrote:
>>
>> [...]
>>
>> > enum devlink_attr {
>> >/* don't chang
Thu, Oct 01, 2020 at 03:59:19PM CEST, mo...@mellanox.com wrote:
>Add devlink reload rst documentation file.
>Update index file to include it.
>
>Signed-off-by: Moshe Shemesh
>---
>RFCv5 -> v1:
>- Rename reload_action_limit_level to reload_limit
>RFCv4 -> RFCv5:
>- Rephrase namespace chnage
Thu, Oct 01, 2020 at 03:59:08PM CEST, mo...@mellanox.com wrote:
>Add remote reload stats to hold the history of actions performed due
>devlink reload commands initiated by remote host. For example, in case
>firmware activation with reset finished successfully but was initiated
>by remote host.
>
Thu, Oct 01, 2020 at 03:59:07PM CEST, mo...@mellanox.com wrote:
>Add reload stats to hold the history per reload action type and limit.
>
>For example, the number of times fw_activate has been performed on this
>device since the driver module was added or if the firmware activation
>was performed
Thu, Oct 01, 2020 at 03:59:05PM CEST, mo...@mellanox.com wrote:
[...]
>+static int
>+devlink_nl_reload_actions_performed_snd(struct devlink *devlink,
>+ unsigned long actions_performed,
>+ enum devlink_command cmd, struct
Thu, Oct 01, 2020 at 03:59:06PM CEST, mo...@mellanox.com wrote:
[...]
> enum devlink_attr {
> /* don't change the order or add anything between, this is ABI! */
> DEVLINK_ATTR_UNSPEC,
>@@ -507,6 +524,7 @@ enum devlink_attr {
>
> DEVLINK_ATTR_RELOAD_ACTION, /* u8 */
struct netlink_ext_ack *extack, unsigned long
>*actions_performed);
Nit. Could you please push extack to be the last arg here? It is common
to have extack as the last arg + action and actions_performed are going
to be side by side.
Otherwise the patch looks fine.
Reviewed-by: Jiri Pirko
is allocated.
>
>Signed-off-by: Moshe Shemesh
Reviewed-by: Jiri Pirko
Thu, Oct 01, 2020 at 12:30:18PM CEST, henrik.bjoernl...@microchip.com wrote:
>This is the definition of the CFM switchdev interface.
>
>The interface consist of these objects:
>SWITCHDEV_OBJ_ID_MEP_CFM,
>SWITCHDEV_OBJ_ID_MEP_CONFIG_CFM,
>SWITCHDEV_OBJ_ID_CC_CONFIG_CFM,
>
Fri, Sep 18, 2020 at 06:13:59PM CEST, mo...@nvidia.com wrote:
>
>On 9/15/2020 11:33 PM, Moshe Shemesh wrote:
>> External email: Use caution opening links or attachments
>>
>>
>> On 9/15/2020 4:34 PM, Jiri Pirko wrote:
>> > Tue, Sep 15, 2020 at 02:31:38PM CE
Tue, Sep 15, 2020 at 10:28:44PM CEST, mo...@nvidia.com wrote:
>
>On 9/15/2020 4:37 PM, Jiri Pirko wrote:
>> Tue, Sep 15, 2020 at 02:44:02PM CEST, mo...@nvidia.com wrote:
>> > On 9/14/2020 4:54 PM, Jiri Pirko wrote:
>> > > Mon, Sep 14, 2020 at 08:07:57
Tue, Sep 15, 2020 at 10:20:39PM CEST, mo...@nvidia.com wrote:
>
>On 9/15/2020 4:33 PM, Jiri Pirko wrote:
>> Tue, Sep 15, 2020 at 02:30:19PM CEST, mo...@nvidia.com wrote:
>> > On 9/14/2020 4:39 PM, Jiri Pirko wrote:
>> > > Mon, Sep 14, 2020 at 08:07:50
Tue, Sep 15, 2020 at 02:56:48PM CEST, mo...@nvidia.com wrote:
>
>On 9/15/2020 12:33 AM, Jakub Kicinski wrote:
>> External email: Use caution opening links or attachments
>>
>>
>> On Mon, 14 Sep 2020 09:07:48 +0300 Moshe Shemesh wrote:
>> > @@ -3011,12 +3060,41 @@ static int
Tue, Sep 15, 2020 at 02:12:25PM CEST, mo...@nvidia.com wrote:
>
>On 9/14/2020 3:27 PM, Jiri Pirko wrote:
>> Mon, Sep 14, 2020 at 08:07:48AM CEST, mo...@mellanox.com wrote:
[..]
>> > @@ -7392,6 +7485,11 @@ struct devlink *devlink_alloc(const struct
>>
Tue, Sep 15, 2020 at 02:30:19PM CEST, mo...@nvidia.com wrote:
>
>On 9/14/2020 4:39 PM, Jiri Pirko wrote:
>> Mon, Sep 14, 2020 at 08:07:50AM CEST, mo...@mellanox.com wrote:
[..]
>> > +/**
>> > + *devlink_reload_implicit_actions_performed - Update d
Tue, Sep 15, 2020 at 02:31:38PM CEST, mo...@nvidia.com wrote:
>
>On 9/15/2020 10:44 AM, Jiri Pirko wrote:
>> Tue, Sep 15, 2020 at 08:45:19AM CEST, ido...@idosch.org wrote:
>> > On Mon, Sep 14, 2020 at 03:45:00PM +0200, Jiri Pirko wrote:
>> > > Mon, Se
Tue, Sep 15, 2020 at 02:44:02PM CEST, mo...@nvidia.com wrote:
>
>On 9/14/2020 4:54 PM, Jiri Pirko wrote:
>> Mon, Sep 14, 2020 at 08:07:57AM CEST, mo...@mellanox.com wrote:
>>
>> [..]
>>
>> > +static void mlx5_fw_reset_complete_reload(struct mlx
Tue, Sep 15, 2020 at 08:45:19AM CEST, ido...@idosch.org wrote:
>On Mon, Sep 14, 2020 at 03:45:00PM +0200, Jiri Pirko wrote:
>> Mon, Sep 14, 2020 at 08:07:51AM CEST, mo...@mellanox.com wrote:
>> >Expose devlink reload actions stats to the user through devlink dev
>> >get
Tue, Sep 15, 2020 at 12:06:19AM CEST, michael.c...@broadcom.com wrote:
>On Mon, Sep 14, 2020 at 2:31 PM Jakub Kicinski wrote:
>>
>> On Mon, 14 Sep 2020 13:28:29 +0200 Jiri Pirko wrote:
>> > >> Instead, why don't you block in reload_up() until the reset is comp
s multi-host setup. Once the user set this parameter to
>false, the driver should NACK any attempt to reset the device while the
>driver is loaded.
>
>Signed-off-by: Moshe Shemesh
Reviewed-by: Jiri Pirko
Mon, Sep 14, 2020 at 08:07:57AM CEST, mo...@mellanox.com wrote:
[..]
>+static void mlx5_fw_reset_complete_reload(struct mlx5_core_dev *dev)
>+{
>+ struct mlx5_fw_reset *fw_reset = dev->priv.fw_reset;
>+
>+ /* if this is the driver that initiated the fw reset, devlink completed
>the
Mon, Sep 14, 2020 at 08:07:57AM CEST, mo...@mellanox.com wrote:
>Add support for devlink reload action fw_activate. To activate firmware
>image the mlx5 driver resets the firmware and reloads it from flash. If
>a new image was stored on flash it will be loaded. Once this reload
>command is
Mon, Sep 14, 2020 at 08:07:51AM CEST, mo...@mellanox.com wrote:
>Expose devlink reload actions stats to the user through devlink dev
>get command.
>
>Examples:
>$ devlink dev show
>pci/:82:00.0:
> reload_action_stats:
>driver_reinit 2
>fw_activate 1
>driver_reinit_no_reset 0
>
Mon, Sep 14, 2020 at 08:07:50AM CEST, mo...@mellanox.com wrote:
>Add reload action stats to hold the history per reload action type and
>limit level.
Empty line missing.
>For example, the number of times fw_activate has been performed on this
>device since the driver module was added or if the
Mon, Sep 14, 2020 at 08:07:49AM CEST, mo...@mellanox.com wrote:
[..]
>diff --git a/include/net/devlink.h b/include/net/devlink.h
>index b09db891db04..9ee5b8a9 100644
>--- a/include/net/devlink.h
>+++ b/include/net/devlink.h
>@@ -1012,9 +1012,13 @@ enum
Mon, Sep 14, 2020 at 08:07:48AM CEST, mo...@mellanox.com wrote:
>Add devlink reload action to allow the user to request a specific reload
>action. The action parameter is optional, if not specified then devlink
>driver re-init action is used (backward compatible).
>Note that when required to do
Mon, Sep 14, 2020 at 11:54:55AM CEST, vasundhara-v.vo...@broadcom.com wrote:
>On Mon, Sep 14, 2020 at 3:02 PM Jiri Pirko wrote:
>>
>> Mon, Sep 14, 2020 at 09:08:58AM CEST, vasundhara-v.vo...@broadcom.com wrote:
>> >On Mon, Sep 14, 2020 at 11:39
Mon, Sep 14, 2020 at 08:08:02AM CEST, mo...@mellanox.com wrote:
>Add devlink reload rst documentation file.
>Update index file to include it.
>
>Signed-off-by: Moshe Shemesh
>---
>v3 -> v4:
>- Remove reload action fw_activate_no_reset
>- Add reload actions limit levels and document the no_reset
Mon, Sep 14, 2020 at 09:08:58AM CEST, vasundhara-v.vo...@broadcom.com wrote:
>On Mon, Sep 14, 2020 at 11:39 AM Moshe Shemesh wrote:
[...]
>> @@ -1126,15 +1126,24 @@ mlxsw_devlink_core_bus_device_reload_down(struct
>> devlink *devlink,
>> }
>>
>> static int
>>
Wed, Sep 09, 2020 at 03:27:19PM CEST, mo...@nvidia.com wrote:
>
>On 9/7/2020 8:58 PM, Jakub Kicinski wrote:
>> On Mon, 7 Sep 2020 16:46:01 +0300 Moshe Shemesh wrote:
>> > > In that sense I don't like --live because it doesn't really say much.
>> > > AFAIU it means 1) no link flap; 2) < 2 sec
Wed, Sep 02, 2020 at 05:32:11PM CEST, a...@mellanox.com wrote:
>Bundle the trap related lists: trap_list, trap_group_list and
>trap_policer_list and trap ops like: trap_init, trap_fini,
>trap_action_set... together in trap_mngr. This will be handy in the
>coming patches in the set introducing
Sun, Sep 06, 2020 at 05:44:28PM CEST, ido...@idosch.org wrote:
>On Wed, Sep 02, 2020 at 06:32:12PM +0300, Aya Levin wrote:
[...]
>
>I understand how this struct allows you to re-use a lot of code between
>per-device and per-port traps, but it's mainly enabled by the fact that
>you use the same
Thu, Sep 03, 2020 at 09:47:19PM CEST, k...@kernel.org wrote:
>On Thu, 3 Sep 2020 07:57:29 +0200 Jiri Pirko wrote:
>> Wed, Sep 02, 2020 at 05:30:25PM CEST, k...@kernel.org wrote:
>> >On Wed, 2 Sep 2020 11:46:27 +0200 Jiri Pirko wrote:
>> >> >? Do we n
Wed, Sep 02, 2020 at 05:30:25PM CEST, k...@kernel.org wrote:
>On Wed, 2 Sep 2020 11:46:27 +0200 Jiri Pirko wrote:
>> >? Do we need such change there too or keep it as is, each action by itself
>> >and return what was performed ?
>>
>> Well, I don't know. User
Tue, Sep 01, 2020 at 09:43:00PM CEST, mo...@nvidia.com wrote:
>
>On 8/31/2020 3:15 PM, Jiri Pirko wrote:
>> Sun, Aug 30, 2020 at 05:27:21PM CEST, mo...@mellanox.com wrote:
>> > Add devlink reload action to allow the user to request a specific reload
>> > action. Th
Tue, Sep 01, 2020 at 09:16:17PM CEST, mo...@nvidia.com wrote:
>
>On 8/31/2020 1:49 PM, Jiri Pirko wrote:
>> Sun, Aug 30, 2020 at 05:27:20PM CEST, mo...@mellanox.com wrote:
>> > Introduce new option on devlink reload API to enable the user to select the
>> > reload act
Sun, Aug 30, 2020 at 05:27:21PM CEST, mo...@mellanox.com wrote:
>Add devlink reload action to allow the user to request a specific reload
>action. The action parameter is optional, if not specified then devlink
>driver re-init action is used (backward compatible).
>Note that when required to do
Sun, Aug 30, 2020 at 05:27:20PM CEST, mo...@mellanox.com wrote:
>Introduce new option on devlink reload API to enable the user to select the
>reload action required. Complete support for all actions in mlx5.
>The following reload actions are supported:
> driver_reinit: driver entities
Sun, Aug 30, 2020 at 05:27:22PM CEST, mo...@mellanox.com wrote:
>Add reload actions counters to hold the history per reload action type.
>For example, the number of times fw_activate has been done on this
>device since the driver module was added or if the firmware activation
>was done with or
Sun, Aug 30, 2020 at 05:27:23PM CEST, mo...@mellanox.com wrote:
>Expose devlink reload actions counters to the user through devlink dev
>get command.
>
>Examples:
>$ devlink dev show
>pci/:82:00.0:
> reload_actions_stats:
>driver_reinit 2
>fw_activate 1
>fw_activate_no_reset 0
Wed, Aug 19, 2020 at 06:25:51PM CEST, k...@kernel.org wrote:
>On Wed, 19 Aug 2020 17:18:15 +0200 Jiri Pirko wrote:
>>>>> I will add counters on which reload were done. reload_down()/up() can
>>>>> return
>>>>> which actions were actually done and
Wed, Aug 19, 2020 at 04:23:25PM CEST, mo...@nvidia.com wrote:
>
>On 8/19/2020 3:46 PM, Jiri Pirko wrote:
>> Wed, Aug 19, 2020 at 02:18:22PM CEST, mo...@nvidia.com wrote:
>> > On 8/19/2020 3:10 AM, Jakub Kicinski wrote:
>> > > On Tue, 18 Aug 2020 12:10:36 +0300 Mosh
Wed, Aug 19, 2020 at 02:18:22PM CEST, mo...@nvidia.com wrote:
>
>On 8/19/2020 3:10 AM, Jakub Kicinski wrote:
>>
>> On Tue, 18 Aug 2020 12:10:36 +0300 Moshe Shemesh wrote:
>> > On 8/17/2020 7:36 PM, Jiri Pirko wrote:
>> > > Mon, Aug 17, 2020 at 11
Tue, Aug 18, 2020 at 11:14:16AM CEST, mo...@nvidia.com wrote:
>
>On 8/17/2020 7:39 PM, Jiri Pirko wrote:
>> Mon, Aug 17, 2020 at 11:37:52AM CEST, mo...@mellanox.com wrote:
>> > Add devlink reload rst documentation file.
>> > Update index file to include it.
>>
Mon, Aug 17, 2020 at 11:37:40AM CEST, mo...@mellanox.com wrote:
>Add devlink reload action to allow the user to request a specific reload
>action. The action parameter is optional, if not specified then devlink
>driver re-init action is used (backward compatible).
>Note that when required to do
Mon, Aug 17, 2020 at 11:37:52AM CEST, mo...@mellanox.com wrote:
>Add devlink reload rst documentation file.
>Update index file to include it.
>
>Signed-off-by: Moshe Shemesh
>---
>- Instead of reload levels driver,fw_reset,fw_live_patch have reload
> actions
Mon, Aug 10, 2020 at 06:53:05PM CEST, k...@kernel.org wrote:
>On Sun, 9 Aug 2020 16:21:29 +0300 Moshe Shemesh wrote:
>> Okay, so devlink reload default for mlx5 will include also fw-activate
>> to align with mlxsw default.
>>
>> Meaning drivers that supports fw-activate will add it to the
Tue, Aug 04, 2020 at 10:39:46PM CEST, k...@kernel.org wrote:
>On Tue, 4 Aug 2020 12:04:18 +0200 Jiri Pirko wrote:
>> Mon, Aug 03, 2020 at 10:57:03PM CEST, k...@kernel.org wrote:
>> >I was trying to avoid having to provide a Cartesian product of
>> >operation and syst
Mon, Aug 03, 2020 at 10:57:03PM CEST, k...@kernel.org wrote:
>On Mon, 3 Aug 2020 16:14:42 +0200 Jiri Pirko wrote:
>> >devlink dev reload [ net-ns-respawn { PID | NAME | ID } ] [
>> >driver-param-init
>> >] [ fw-activate [ --live] ]
>>
>> Jakub, why
Sat, Aug 01, 2020 at 11:32:25PM CEST, mo...@mellanox.com wrote:
>
>On 7/31/2020 2:11 AM, Jakub Kicinski wrote:
>> On Thu, 30 Jul 2020 15:30:45 +0300 Moshe Shemesh wrote:
>> > > > > My expectations would be that the driver must perform the lowest
>> > > > > reset level possible that satisfies the
Tue, Jul 28, 2020 at 02:58:02AM CEST, k...@kernel.org wrote:
>On Mon, 27 Jul 2020 14:02:21 +0300 Moshe Shemesh wrote:
>> Add devlink reload level to allow the user to request a specific reload
>> level. The level parameter is optional, if not specified then driver's
>> default reload level is used
Mon, Jul 27, 2020 at 03:29:17PM CEST, andy.shevche...@gmail.com wrote:
>On Mon, Jul 27, 2020 at 3:23 PM Vadym Kochan wrote:
[...]
>
>> + pci_set_drvdata(pdev, fw);
>> +
>> + err = prestera_fw_init(fw);
>> + if (err)
>> + goto err_prestera_fw_init;
>> +
>> +
Mon, Jul 27, 2020 at 02:35:53PM CEST, vadym.koc...@plvision.eu wrote:
>Hi Jiri,
>
>On Mon, Jul 27, 2020 at 02:32:05PM +0200, Jiri Pirko wrote:
>> Mon, Jul 27, 2020 at 02:22:38PM CEST, vadym.koc...@plvision.eu wrote:
>> >Add PCI interface driver for Prestera Switch ASI
ATCH version.
>
>Signed-off-by: Oleksandr Mazur
>Signed-off-by: Vadym Kochan
>Acked-by: Jiri Pirko
You have to remove the tag if you change the patch from last tagged
version...
>---
>PATCH v4:
>1) Get rid of "packed" attribute for the fw
version.
>
>Signed-off-by: Oleksandr Mazur
>Signed-off-by: Vadym Kochan
Looks fine.
Acked-by: Jiri Pirko
Sat, Jul 25, 2020 at 05:06:49PM CEST, vadym.koc...@plvision.eu wrote:
>The ethtool API provides support for the configuration of the following
>features: speed and duplex, auto-negotiation, MDI-x, forward error
>correction, port media type. The API also provides information about the
>port status,
Sat, Jul 25, 2020 at 05:06:48PM CEST, vadym.koc...@plvision.eu wrote:
>Add very basic support for devlink interface:
>
>- driver name
>- fw version
>- devlink ports
>
>Signed-off-by: Vadym Kochan
Reviewed-by: Jiri Pirko
Sat, Jul 25, 2020 at 05:06:46PM CEST, vadym.koc...@plvision.eu wrote:
>Marvell Prestera 98DX326x integrates up to 24 ports of 1GbE with 8
>ports of 10GbE uplinks or 2 ports of 40Gbps stacking for a largely
>wireless SMB deployment.
>
>The current implementation supports only boards designed for
Sat, Jul 25, 2020 at 05:06:50PM CEST, vadym.koc...@plvision.eu wrote:
>The following features are supported:
>
>- VLAN-aware bridge offloading
>- VLAN-unaware bridge offloading
>- FDB offloading (learning, ageing)
>- Switchport configuration
>
>Currently there are some limitations
Fri, Jul 24, 2020 at 04:19:51PM CEST, vadym.koc...@plvision.eu wrote:
>Marvell Prestera 98DX326x integrates up to 24 ports of 1GbE with 8
>ports of 10GbE uplinks or 2 ports of 40Gbps stacking for a largely
>wireless SMB deployment.
>
>Prestera Switchdev is a firmware based driver that operates via
Sat, Jul 04, 2020 at 01:44:39AM CEST, k...@kernel.org wrote:
>On Fri, 3 Jul 2020 06:27:31 +0300 Moshe Shemesh wrote:
>> Implement support for devlink health reporters on per-port basis. First
>> part in the series prepares common functions parts for health reporter
>> implementation. Second
Thu, May 28, 2020 at 05:12:42PM CEST, vadym.koc...@plvision.eu wrote:
>Add very basic support for devlink interface:
>
>- driver name
>- fw version
>- devlink ports
>
>Signed-off-by: Vadym Kochan
>---
> drivers/net/ethernet/marvell/prestera/Kconfig | 1 +
>
Wed, Jun 03, 2020 at 04:29:44PM CEST, j...@resnulli.us wrote:
>Thu, May 28, 2020 at 05:12:40PM CEST, vadym.koc...@plvision.eu wrote:
>
>[...]
>
>>+static int prestera_port_create(struct prestera_switch *sw, u32 id)
>>+{
>>+ struct prestera_port *port;
>>+ struct net_device *dev;
>>+
Thu, May 28, 2020 at 05:12:40PM CEST, vadym.koc...@plvision.eu wrote:
[...]
>+static int prestera_port_create(struct prestera_switch *sw, u32 id)
>+{
>+ struct prestera_port *port;
>+ struct net_device *dev;
>+ int err;
>+
>+ dev = alloc_etherdev(sizeof(*port));
>+ if
Thu, May 28, 2020 at 05:12:40PM CEST, vadym.koc...@plvision.eu wrote:
[...]
>+}
>+
>+int prestera_hw_port_info_get(const struct prestera_port *port,
>+u16 *fp_id, u32 *hw_id, u32 *dev_id)
Please unify the ordering of "hw_id" and "dev_id" with the rest of the
Sat, May 30, 2020 at 05:54:29PM CEST, ido...@idosch.org wrote:
>On Sat, May 30, 2020 at 05:52:31PM +0300, Vadym Kochan wrote:
[...]
>> > WARNING: do not add new typedefs
>> > #1064: FILE: drivers/net/ethernet/marvell/prestera/prestera_hw.h:32:
>> > +typedef void (*prestera_event_cb_t)
>> I may
Mon, Oct 14, 2019 at 01:18:47PM CEST, mkube...@suse.cz wrote:
>On Fri, Oct 11, 2019 at 03:34:29PM +0200, Jiri Pirko wrote:
>> Wed, Oct 09, 2019 at 10:59:18PM CEST, mkube...@suse.cz wrote:
>> >+Bit sets
>> >+
>> >+
>> >+For short b
Wed, Oct 09, 2019 at 10:59:43PM CEST, mkube...@suse.cz wrote:
[...]
>+static const struct nla_policy linkinfo_hdr_policy[ETHTOOL_A_HEADER_MAX + 1]
>= {
>+ [ETHTOOL_A_HEADER_UNSPEC] = { .type = NLA_REJECT },
>+ [ETHTOOL_A_HEADER_DEV_INDEX]= { .type = NLA_U32
Wed, Oct 09, 2019 at 10:59:18PM CEST, mkube...@suse.cz wrote:
>The ethtool netlink code uses common framework for passing arbitrary
>length bit sets to allow future extensions. A bitset can be a list (only
>one bitmap) or can consist of value and mask pair (used e.g. when client
>want to modify
c10e6cf85e7d ("net: genetlink: push attrbuf allocation and parsing to a
>separate function")
>Signed-off-by: Michal Kubecek
Acked-by: Jiri Pirko
Thanks!
Thu, Oct 10, 2019 at 07:21:02PM CEST, jakub.kicin...@netronome.com wrote:
>On Thu, 10 Oct 2019 12:34:02 +0200 (CEST), Michal Kubecek wrote:
>> Commit c10e6cf85e7d ("net: genetlink: push attrbuf allocation and parsing
>> to a separate function") moved attribute buffer allocation and attribute
>>
Thu, Oct 10, 2019 at 08:04:01PM CEST, mkube...@suse.cz wrote:
>On Thu, Oct 10, 2019 at 03:56:39PM +0200, Jiri Pirko wrote:
>> Wed, Oct 09, 2019 at 10:59:27PM CEST, mkube...@suse.cz wrote:
[...]
>> >+ const struct nlmsghdr *nlhd
Thu, Oct 10, 2019 at 09:30:44PM CEST, mkube...@suse.cz wrote:
>On Thu, Oct 10, 2019 at 05:37:54PM +0200, Jiri Pirko wrote:
>> Wed, Oct 09, 2019 at 10:59:43PM CEST, mkube...@suse.cz wrote:
>> >Implement LINKINFO_SET netlink request to set link settings queried by
>&g
Thu, Oct 10, 2019 at 08:17:43PM CEST, mkube...@suse.cz wrote:
>On Thu, Oct 10, 2019 at 05:25:59PM +0200, Jiri Pirko wrote:
>> Wed, Oct 09, 2019 at 10:59:40PM CEST, mkube...@suse.cz wrote:
[...]
>> >+
>> >+/* generic notification handler */
>> >+static voi
Wed, Oct 09, 2019 at 10:59:37PM CEST, mkube...@suse.cz wrote:
[...]
>+/* prepare_data() handler */
Not sure how valuable are comments like this...
>+static int linkinfo_prepare(const struct ethnl_req_info *req_base,
>+ struct ethnl_reply_data *reply_base,
>+
Wed, Oct 09, 2019 at 10:59:43PM CEST, mkube...@suse.cz wrote:
>Implement LINKINFO_SET netlink request to set link settings queried by
>LINKINFO_GET message.
>
>Only physical port, phy MDIO address and MDI(-X) control can be set,
>attempt to modify MDI(-X) status and transceiver is rejected.
>
Wed, Oct 09, 2019 at 10:59:40PM CEST, mkube...@suse.cz wrote:
>The ethtool netlink notifications have the same format as related GET
>replies so that if generic GET handling framework is used to process GET
>requests, its callbacks and instance of struct get_request_ops can be
>also used to
Wed, Oct 09, 2019 at 10:59:27PM CEST, mkube...@suse.cz wrote:
[...]
>+static const struct get_request_ops *get_requests[__ETHTOOL_MSG_USER_CNT] = {
I think that prefix would be good here as well:
+static const struct ethnl_get_request_ops *
ethnl_get_requests[__ETHTOOL_MSG_USER_CNT] = {
Wed, Oct 09, 2019 at 10:59:30PM CEST, mkube...@suse.cz wrote:
[...]
>+const struct get_request_ops strset_request_ops = {
I think when var is leaving context of single file, it should have
prefix:
ethnl_strset_request_ops
[...]
Wed, Oct 09, 2019 at 10:59:27PM CEST, mkube...@suse.cz wrote:
>Significant part of GET request processing is common for most request
>types but unfortunately it cannot be easily separated from type specific
>code as we need to alternate between common actions (parsing common request
>header,
Wed, Oct 09, 2019 at 10:59:15PM CEST, mkube...@suse.cz wrote:
[...]
>+/**
>+ * ethnl_parse_header() - parse request header
>+ * @req_info:structure to put results into
>+ * @header: nest attribute with request header
>+ * @net: request netns
>+ * @extack: netlink extack
ecek
Reviewed-by: Jiri Pirko
cv_msg_doit() if family->maxattr is zero. Do the
>same also in genl_family_rcv_msg_doit().
>
>Fixes: c10e6cf85e7d ("net: genetlink: push attrbuf allocation and parsing to a
>separate function")
>Signed-off-by: Michal Kubecek
Acked-by: Jiri Pirko
Thanks!
Wed, Oct 09, 2019 at 06:44:32PM CEST, mkube...@suse.cz wrote:
>Commit c10e6cf85e7d ("net: genetlink: push attrbuf allocation and parsing
>to a separate function") moved attribute buffer allocation and attribute
>parsing from genl_family_rcv_msg_doit() into a separate function
1 - 100 of 831 matches
Mail list logo
