Displaying 7 results from an estimated 7 matches for "netdevbpf".
Did you mean:
netdev_bpf
2023 Apr 03
1
[PATCH 0/1] posted interrtups support for mlx5
On 4/3/2023 12:20 PM, Eli Cohen wrote:
> Hi,
>
> the single patch in this series adds support for posted interrupts in
> mlx5.
>
> It depends on the patch series already accpted can be seen here:
> https://patchwork.kernel.org/project/netdevbpf/patch/20230324231341.29808-1-saeed at kernel.org/
>
> git pull git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux.git
> tags/mlx5-updates-2023-03-20
>
> Eli Cohen (1):
> vdpa/mlx5: Support interrupt bypassing
>
> drivers/vdpa/mlx5/net/mlx5_vnet.c | 139 ++++++...
2023 Apr 03
1
[PATCH 0/1] posted interrtups support for mlx5
...> On 4/3/2023 12:20 PM, Eli Cohen wrote:
> > Hi,
> >
> > the single patch in this series adds support for posted interrupts in
> > mlx5.
> >
> > It depends on the patch series already accpted can be seen here:
> > https://patchwork.kernel.org/project/netdevbpf/patch/20230324231341.29808-1-saeed at kernel.org/
> >
> > git pull git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux.git
> > tags/mlx5-updates-2023-03-20
> >
> > Eli Cohen (1):
> > vdpa/mlx5: Support interrupt bypassing
> >
> > driver...
2023 Mar 09
0
[PATCH 3/3] virtio_ring: Use const to annotate read-only pointer params
...ar that this is what it is, and explain why
> >you are posting it now and not after testing.
>
> Isn't there some ci running with posted patches here? That would uncover
> it right away. In netdev world, this is very convenient. Example:
> https://patchwork.kernel.org/project/netdevbpf/list/?series=727865
> Patch won't apply.
It is a best effort thing and is not an excuse to post untested patches
for review. If I see a patch I expect that the author made sure
the patch does what it's supposed to do.
--
MST
2023 Sep 08
0
[PATCH] vdpa: consume device_features parameter
...4 months? Maybe the
>> subject is not clear, but this is an iproute2 patch. Would it be
>> possible to merge at your earliest convenience?
>>
>> PS, adding my R-b to the patch.
>>
> It got marked "Not applicable":
> https://patchwork.kernel.org/project/netdevbpf/patch/29db10bca7e5ef6b1137282292660fc337a4323a.1683907102.git.allen.hubbe at amd.com/
>
> Resend the patch with any reviewed by tags and be sure to cc me.
>
Just out of my own curiosity, the patch is not applicable simply because
the iproute2 was missing from the subject, or the code base...
2023 Sep 08
0
[PATCH] vdpa: consume device_features parameter
...4 months? Maybe the
>> subject is not clear, but this is an iproute2 patch. Would it be
>> possible to merge at your earliest convenience?
>>
>> PS, adding my R-b to the patch.
>>
> It got marked "Not applicable":
> https://patchwork.kernel.org/project/netdevbpf/patch/29db10bca7e5ef6b1137282292660fc337a4323a.1683907102.git.allen.hubbe at amd.com/
>
> Resend the patch with any reviewed by tags and be sure to cc me.
>
Just out of my own curiosity, the patch is not applicable simply because
the iproute2 was missing from the subject, or the code base...
2023 Mar 30
2
[Bridge] [PATCH v2 net-next 2/6] net: dsa: propagate flags down towards drivers
...gt; out dynamic entries. That led me to conclude that this patch-set cannot
> use the offloaded flag, but you seem to suggest otherwise.
>
> If you have a suggestion, feel free.
Didn't I explain what I would do from the first reply on this thread?
https://patchwork.kernel.org/project/netdevbpf/patch/20230318141010.513424-3-netdev at kapio-technology.com/#25270613
As a bug fix, stop reporting to switchdev those FDB entries with
BR_FDB_ADDED_BY_USER && !BR_FDB_STATIC. Then, after "net" is merged into
"net-next" next Thursday (the ship has sailed for today), add...
2023 Mar 30
1
[Bridge] [PATCH v2 net-next 2/6] net: dsa: propagate flags down towards drivers
On Thu, Mar 30, 2023 at 16:09, Vladimir Oltean <olteanv at gmail.com> wrote:
> On Thu, Mar 30, 2023 at 02:59:04PM +0200, Hans Schultz wrote:
>> On Thu, Mar 30, 2023 at 15:43, Vladimir Oltean <olteanv at gmail.com> wrote:
>> > On Tue, Mar 28, 2023 at 09:45:26PM +0200, Hans Schultz wrote:
>> >> So the solution would be to not let the DSA layer send the