* Re: [net PATCH] net: virtio: cap mtu when XDP programs are running
From: Michael S. Tsirkin @ 2017-01-10 3:55 UTC (permalink / raw)
To: John Fastabend
Cc: Jason Wang, john.r.fastabend, netdev, alexei.starovoitov, daniel
In-Reply-To: <5874555A.3070307@gmail.com>
On Mon, Jan 09, 2017 at 07:30:34PM -0800, John Fastabend wrote:
> On 17-01-09 06:51 PM, Michael S. Tsirkin wrote:
> > On Tue, Jan 10, 2017 at 10:29:39AM +0800, Jason Wang wrote:
> >>
> >>
> >> On 2017年01月10日 07:58, Michael S. Tsirkin wrote:
> >>> On Mon, Jan 09, 2017 at 03:49:27PM -0800, John Fastabend wrote:
> >>>> On 17-01-09 03:24 PM, Michael S. Tsirkin wrote:
> >>>>> On Mon, Jan 09, 2017 at 03:13:15PM -0800, John Fastabend wrote:
> >>>>>> On 17-01-09 03:05 PM, Michael S. Tsirkin wrote:
> >>>>>>> On Thu, Jan 05, 2017 at 11:09:14AM +0800, Jason Wang wrote:
> >>>>>>>> On 2017年01月05日 02:57, John Fastabend wrote:
> >>>>>>>>> [...]
> >>>>>>>>>
> >>>>>>>>>> On 2017年01月04日 00:48, John Fastabend wrote:
> >>>>>>>>>>> On 17-01-02 10:14 PM, Jason Wang wrote:
> >>>>>>>>>>>> On 2017年01月03日 06:30, John Fastabend wrote:
> >>>>>>>>>>>>> XDP programs can not consume multiple pages so we cap the MTU to
> >>>>>>>>>>>>> avoid this case. Virtio-net however only checks the MTU at XDP
> >>>>>>>>>>>>> program load and does not block MTU changes after the program
> >>>>>>>>>>>>> has loaded.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> This patch sets/clears the max_mtu value at XDP load/unload time.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Signed-off-by: John Fastabend<john.r.fastabend@intel.com>
> >>>>>>>>>>>>> ---
> >>>>>>>>> [...]
> >>>>>>>>>
> >>>>>>>>>>> OK so this logic is a bit too simply. When it resets the max_mtu I guess it
> >>>>>>>>>>> needs to read the mtu via
> >>>>>>>>>>>
> >>>>>>>>>>> virtio_cread16(vdev, ...)
> >>>>>>>>>>>
> >>>>>>>>>>> or we may break the negotiated mtu.
> >>>>>>>>>> Yes, this is a problem (even use ETH_MAX_MTU). We may need a method to notify
> >>>>>>>>>> the device about the mtu in this case which is not supported by virtio now.
> >>>>>>>>> Note this is not really a XDP specific problem. The guest can change the MTU
> >>>>>>>>> after init time even without XDP which I assume should ideally result in a
> >>>>>>>>> notification if the MTU is negotiated.
> >>>>>>>> Yes, Michael, do you think we need add some mechanism to notify host about
> >>>>>>>> MTU change in this case?
> >>>>>>>>
> >>>>>>>> Thanks
> >>>>>>> Why does host care?
> >>>>>>>
> >>>>>> Well the guest will drop packets after mtu has been reduced.
> >>>>> I didn't know. What place in code does this?
> >>>>>
> >>>> hmm in many of the drivers it is convention to use the mtu to set the rx
> >>>> buffer sizes and a receive side max length filter. For example in the Intel
> >>>> drivers if a packet with length greater than MTU + some headroom is received we
> >>>> drop it. I guess in the networking stack RX path though nothing forces this and
> >>>> virtio doesn't have any code to drop packets on rx size.
> >>>>
> >>>> In virtio I don't see any existing case currently. In the XDP case though we
> >>>> need to ensure packets fit in a page for the time being which is why I was
> >>>> looking at this code and generated this patch.
> >>> I'd say just look at the hardware max mtu. Ignore the configured mtu.
> >>>
> >>>
> >>
> >> Does this work for small buffers consider it always allocate skb with size
> >> of GOOD_PACKET_LEN?
> >
> > Spec says hardware won't send in packets > max mtu in config space.
> >
> >> I think in any case, we should limit max_mtu to
> >> GOOD_PACKET_LEN for small buffers.
> >>
> >> Thanks
> >
> > XDP seems to have a bunch of weird restrictions, I just
> > do not like it that the logic spills out to all drivers.
> > What if someone decides to extend it to two pages in the future?
> > Recode it all in all drivers ...
> >
> > Why can't net core enforce mtu?
> >
>
> OK I agree I'll put most the logic in rtnetlink.c when the program is added
> or removed.
>
> But, I'm looking at the non-XDP receive_small path now and wondering how does
> multiple buffer receives work (e.g. packet larger than GOOD_PACKET_LEN?)
I don't understand the question. Look at add_recvbuf_small,
it adds a tiny buffer for head and then the skb.
> I think
> this is what Jason is looking at as well? The mergeable case clearly looks at
> num_bufs in the descriptor to construct multi-buffer packets but nothing like
> that exists in the small_receive path as best I can tell.
>
> .John
There's always a single buffer there.
BTW it was always a legacy path but if it's now important for people we
should probably check ANY_LAYOUT and put header linearly with the packet
if there.
--
MST
^ permalink raw reply
* Re: [PATCH net-next] bridge: multicast to unicast
From: Linus Lüssing @ 2017-01-10 4:18 UTC (permalink / raw)
To: Stephen Hemminger
Cc: netdev, bridge, linux-wireless, linux-kernel, M. Braun,
Johannes Berg, David S . Miller, Felix Fietkau
In-Reply-To: <20170109133032.221f8669@xeon-e3>
On Mon, Jan 09, 2017 at 01:30:32PM -0800, Stephen Hemminger wrote:
> I wonder if MAC80211 should be doing IGMP snooping and not bridge
> in this environment.
In the long term, yes. For now, not quite sure.
I personally like to go for simple solutions first :).
^ permalink raw reply
* Re: [for-next V2 08/10] IB/mlx5: Allow future extension of libmlx5 input data
From: Doug Ledford @ 2017-01-10 4:24 UTC (permalink / raw)
To: Saeed Mahameed, David S. Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
Leon Romanovsky, Eli Cohen, Matan Barak, Leon Romanovsky
In-Reply-To: <1483890891-8767-9-git-send-email-saeedm-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 776 bytes --]
On Sun, 2017-01-08 at 17:54 +0200, Saeed Mahameed wrote:
> From: Eli Cohen <eli-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
>
> Current check requests that new fields in struct
> mlx5_ib_alloc_ucontext_req_v2 that are not known to the driver be
> zero.
> This was introduced so new libraries passing additional information
> to
> the kernel through struct mlx5_ib_alloc_ucontext_req_v2 will be
> notified
> by old kernels that do not support their request by failing the
> operation. This schecme is problematic since it requires libmlx5 to
^ Typo
--
Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [net PATCH] net: virtio: cap mtu when XDP programs are running
From: John Fastabend @ 2017-01-10 4:25 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Jason Wang, john.r.fastabend, netdev, alexei.starovoitov, daniel
In-Reply-To: <20170110055023-mutt-send-email-mst@kernel.org>
On 17-01-09 07:55 PM, Michael S. Tsirkin wrote:
> On Mon, Jan 09, 2017 at 07:30:34PM -0800, John Fastabend wrote:
>> On 17-01-09 06:51 PM, Michael S. Tsirkin wrote:
>>> On Tue, Jan 10, 2017 at 10:29:39AM +0800, Jason Wang wrote:
>>>>
>>>>
>>>> On 2017年01月10日 07:58, Michael S. Tsirkin wrote:
>>>>> On Mon, Jan 09, 2017 at 03:49:27PM -0800, John Fastabend wrote:
>>>>>> On 17-01-09 03:24 PM, Michael S. Tsirkin wrote:
>>>>>>> On Mon, Jan 09, 2017 at 03:13:15PM -0800, John Fastabend wrote:
>>>>>>>> On 17-01-09 03:05 PM, Michael S. Tsirkin wrote:
>>>>>>>>> On Thu, Jan 05, 2017 at 11:09:14AM +0800, Jason Wang wrote:
>>>>>>>>>> On 2017年01月05日 02:57, John Fastabend wrote:
>>>>>>>>>>> [...]
>>>>>>>>>>>
>>>>>>>>>>>> On 2017年01月04日 00:48, John Fastabend wrote:
>>>>>>>>>>>>> On 17-01-02 10:14 PM, Jason Wang wrote:
>>>>>>>>>>>>>> On 2017年01月03日 06:30, John Fastabend wrote:
>>>>>>>>>>>>>>> XDP programs can not consume multiple pages so we cap the MTU to
>>>>>>>>>>>>>>> avoid this case. Virtio-net however only checks the MTU at XDP
>>>>>>>>>>>>>>> program load and does not block MTU changes after the program
>>>>>>>>>>>>>>> has loaded.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This patch sets/clears the max_mtu value at XDP load/unload time.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Signed-off-by: John Fastabend<john.r.fastabend@intel.com>
>>>>>>>>>>>>>>> ---
>>>>>>>>>>> [...]
>>>>>>>>>>>
>>>>>>>>>>>>> OK so this logic is a bit too simply. When it resets the max_mtu I guess it
>>>>>>>>>>>>> needs to read the mtu via
>>>>>>>>>>>>>
>>>>>>>>>>>>> virtio_cread16(vdev, ...)
>>>>>>>>>>>>>
>>>>>>>>>>>>> or we may break the negotiated mtu.
>>>>>>>>>>>> Yes, this is a problem (even use ETH_MAX_MTU). We may need a method to notify
>>>>>>>>>>>> the device about the mtu in this case which is not supported by virtio now.
>>>>>>>>>>> Note this is not really a XDP specific problem. The guest can change the MTU
>>>>>>>>>>> after init time even without XDP which I assume should ideally result in a
>>>>>>>>>>> notification if the MTU is negotiated.
>>>>>>>>>> Yes, Michael, do you think we need add some mechanism to notify host about
>>>>>>>>>> MTU change in this case?
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>> Why does host care?
>>>>>>>>>
>>>>>>>> Well the guest will drop packets after mtu has been reduced.
>>>>>>> I didn't know. What place in code does this?
>>>>>>>
>>>>>> hmm in many of the drivers it is convention to use the mtu to set the rx
>>>>>> buffer sizes and a receive side max length filter. For example in the Intel
>>>>>> drivers if a packet with length greater than MTU + some headroom is received we
>>>>>> drop it. I guess in the networking stack RX path though nothing forces this and
>>>>>> virtio doesn't have any code to drop packets on rx size.
>>>>>>
>>>>>> In virtio I don't see any existing case currently. In the XDP case though we
>>>>>> need to ensure packets fit in a page for the time being which is why I was
>>>>>> looking at this code and generated this patch.
>>>>> I'd say just look at the hardware max mtu. Ignore the configured mtu.
>>>>>
>>>>>
>>>>
>>>> Does this work for small buffers consider it always allocate skb with size
>>>> of GOOD_PACKET_LEN?
>>>
>>> Spec says hardware won't send in packets > max mtu in config space.
>>>
>>>> I think in any case, we should limit max_mtu to
>>>> GOOD_PACKET_LEN for small buffers.
>>>>
>>>> Thanks
>>>
>>> XDP seems to have a bunch of weird restrictions, I just
>>> do not like it that the logic spills out to all drivers.
>>> What if someone decides to extend it to two pages in the future?
>>> Recode it all in all drivers ...
>>>
>>> Why can't net core enforce mtu?
>>>
>>
>> OK I agree I'll put most the logic in rtnetlink.c when the program is added
>> or removed.
>>
>> But, I'm looking at the non-XDP receive_small path now and wondering how does
>> multiple buffer receives work (e.g. packet larger than GOOD_PACKET_LEN?)
>
> I don't understand the question. Look at add_recvbuf_small,
> it adds a tiny buffer for head and then the skb.
>
Specifically this seems to fail with mergeable buffers disabled
On the host:
# ip link set dev tap0 mtu 9000
# ping 22.2 -s 2048
On the guest:
# insmod ./drivers/net/virtio_net.ko
# ip link set dev eth0 mtu 9000
With mergeable buffers enabled no problems it works as I expect at least.
>
>> I think
>> this is what Jason is looking at as well? The mergeable case clearly looks at
>> num_bufs in the descriptor to construct multi-buffer packets but nothing like
>> that exists in the small_receive path as best I can tell.
>>
>> .John
>
> There's always a single buffer there.
> BTW it was always a legacy path but if it's now important for people we
> should probably check ANY_LAYOUT and put header linearly with the packet
> if there.
>
^ permalink raw reply
* Re: [for-next V2 00/10][pull request] Mellanox 100G mlx5 4K UAR support
From: Doug Ledford @ 2017-01-10 4:29 UTC (permalink / raw)
To: Saeed Mahameed, David S. Miller
Cc: netdev, linux-rdma, Leon Romanovsky, Eli Cohen, Matan Barak
In-Reply-To: <1483890891-8767-1-git-send-email-saeedm@mellanox.com>
[-- Attachment #1: Type: text/plain, Size: 828 bytes --]
On Sun, 2017-01-08 at 17:54 +0200, Saeed Mahameed wrote:
> Hi Dave and Doug,
>
> Following the mlx5-odp submission, you can find here the 2nd mlx5
> submission for 4.11 as a pull-request including mlx5 4K UAR support
> from
> Eli Cohen (details below). For you Doug, this pull request will
> provide
> you with both mlx5 odp and mlx5 4k UAR since it is based on Dave's
> net-next mlx5-odp merge commit.
>
> v1->v2:
> - Removed 64BIT arch dependency.
>
> Thank you,
> Saeed.
>
I know you have a couple issues to fix on respin (minor things as
pointed out). Otherwise, I've reviewed of the IB portion of the code
and have no objections.
--
Doug Ledford <dledford@redhat.com>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [for-next V3 00/10][pull request] Mellanox 100G mlx5 4K UAR support
From: Doug Ledford @ 2017-01-10 4:53 UTC (permalink / raw)
To: Saeed Mahameed, David S. Miller
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, linux-rdma-u79uwXL29TY76Z2rM5mHXA,
Leon Romanovsky, Eli Cohen, Matan Barak
In-Reply-To: <1483988453-28551-1-git-send-email-saeedm-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 4292 bytes --]
On Mon, 2017-01-09 at 21:00 +0200, Saeed Mahameed wrote:
> Hi Dave and Doug,
>
> Following the mlx5-odp submission, you can find here the 2nd mlx5
> submission for 4.11 as a pull-request including mlx5 4K UAR support
> from
> Eli Cohen (details below). For you Doug, this pull request will
> provide
> you with both mlx5 odp and mlx5 4k UAR since it is based on Dave's
> net-next mlx5-odp merge commit.
>
> v1->v2:
> - Removed 64BIT arch dependency.
> v2->v3:
> - Removed extra space.
>
> Thank you,
> Saeed.
>
> The following changes since commit
> 525dfa2cdce4f5ab76251b5e57ebabf4f2dfc40c:
>
> Merge branch 'mlx5-odp' (2017-01-02 15:51:21 -0500)
This base commit looks harmless enough, but since it's likely just a
commit in your tree, it isn't really a clear indicator of how you set
this tree up....
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git
> tags/mlx5-4kuar-for-4.11
>
> for you to fetch changes up to
> f502d834950a28e02651bb7e2cc7111ddd352644:
>
> net/mlx5: Activate support for 4K UARs (2017-01-09 20:25:10 +0200)
But once I pulled this, it became clear you guys based your tree on a
net-next starting point. You need to make that clear in the beginning.
And unless you can't avoid it, don't do it. I don't like having to
pull in Dave's net-next before I pull your code because it means I
can't submit my pull request to Linus during the merge window as a
single pull request, I have to split it up to be the stuff that is
based on net-next and the stuff based on my own next area.
>
> ----------------------------------------------------------------
> Eli Cohen (10):
> IB/mlx5: Fix kernel to user leak prevention logic
> IB/mlx5: Fix error handling order in create_kernel_qp
> mlx5: Fix naming convention with respect to UARs
> IB/mlx5: Fix retrieval of index to first hi class bfreg
> net/mlx5: Introduce blue flame register allocator
> net/mlx5: Add interface to get reference to a UAR
> IB/mlx5: Use blue flame register allocator in mlx5_ib
> IB/mlx5: Allow future extension of libmlx5 input data
> IB/mlx5: Support 4k UAR for libmlx5
> net/mlx5: Activate support for 4K UARs
>
> drivers/infiniband/hw/mlx5/cq.c | 10 +-
> drivers/infiniband/hw/mlx5/main.c | 278 ++++++++++-
> -----
> drivers/infiniband/hw/mlx5/mlx5_ib.h | 32 +-
> drivers/infiniband/hw/mlx5/qp.c | 290 +++++++--
> --------
> drivers/net/ethernet/mellanox/mlx5/core/cq.c | 2 +
> drivers/net/ethernet/mellanox/mlx5/core/en.h | 11 +-
> .../net/ethernet/mellanox/mlx5/core/en_common.c | 12 +-
> drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 21 +-
> drivers/net/ethernet/mellanox/mlx5/core/eq.c | 14 +-
> drivers/net/ethernet/mellanox/mlx5/core/main.c | 26 +-
> drivers/net/ethernet/mellanox/mlx5/core/uar.c | 351
> +++++++++++++--------
> include/linux/mlx5/cq.h | 5 +-
> include/linux/mlx5/device.h | 23 +-
> include/linux/mlx5/doorbell.h | 6 +-
> include/linux/mlx5/driver.h | 81 ++---
> include/linux/mlx5/mlx5_ifc.h | 7 +-
> include/uapi/rdma/mlx5-abi.h | 19 +-
> 17 files changed, 672 insertions(+), 516 deletions(-)
Without going into excruciating detail, this is what I got when I
pulled your branch:
273 files changed, 8891 insertions(+), 6637 deletions(-)
create mode 100644 drivers/net/ethernet/qlogic/qede/qede_filter.c
create mode 100644 drivers/net/ethernet/qlogic/qede/qede_fp.c
Please don't do this unless you absolutely have to.
--
Doug Ledford <dledford@redhat.com>
GPG KeyID: B826A3330E572FDD
Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [net PATCH] net: virtio: cap mtu when XDP programs are running
From: Michael S. Tsirkin @ 2017-01-10 5:00 UTC (permalink / raw)
To: John Fastabend
Cc: Jason Wang, john.r.fastabend, netdev, alexei.starovoitov, daniel
In-Reply-To: <58746247.604@gmail.com>
On Mon, Jan 09, 2017 at 08:25:43PM -0800, John Fastabend wrote:
> On 17-01-09 07:55 PM, Michael S. Tsirkin wrote:
> > On Mon, Jan 09, 2017 at 07:30:34PM -0800, John Fastabend wrote:
> >> On 17-01-09 06:51 PM, Michael S. Tsirkin wrote:
> >>> On Tue, Jan 10, 2017 at 10:29:39AM +0800, Jason Wang wrote:
> >>>>
> >>>>
> >>>> On 2017年01月10日 07:58, Michael S. Tsirkin wrote:
> >>>>> On Mon, Jan 09, 2017 at 03:49:27PM -0800, John Fastabend wrote:
> >>>>>> On 17-01-09 03:24 PM, Michael S. Tsirkin wrote:
> >>>>>>> On Mon, Jan 09, 2017 at 03:13:15PM -0800, John Fastabend wrote:
> >>>>>>>> On 17-01-09 03:05 PM, Michael S. Tsirkin wrote:
> >>>>>>>>> On Thu, Jan 05, 2017 at 11:09:14AM +0800, Jason Wang wrote:
> >>>>>>>>>> On 2017年01月05日 02:57, John Fastabend wrote:
> >>>>>>>>>>> [...]
> >>>>>>>>>>>
> >>>>>>>>>>>> On 2017年01月04日 00:48, John Fastabend wrote:
> >>>>>>>>>>>>> On 17-01-02 10:14 PM, Jason Wang wrote:
> >>>>>>>>>>>>>> On 2017年01月03日 06:30, John Fastabend wrote:
> >>>>>>>>>>>>>>> XDP programs can not consume multiple pages so we cap the MTU to
> >>>>>>>>>>>>>>> avoid this case. Virtio-net however only checks the MTU at XDP
> >>>>>>>>>>>>>>> program load and does not block MTU changes after the program
> >>>>>>>>>>>>>>> has loaded.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> This patch sets/clears the max_mtu value at XDP load/unload time.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Signed-off-by: John Fastabend<john.r.fastabend@intel.com>
> >>>>>>>>>>>>>>> ---
> >>>>>>>>>>> [...]
> >>>>>>>>>>>
> >>>>>>>>>>>>> OK so this logic is a bit too simply. When it resets the max_mtu I guess it
> >>>>>>>>>>>>> needs to read the mtu via
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> virtio_cread16(vdev, ...)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> or we may break the negotiated mtu.
> >>>>>>>>>>>> Yes, this is a problem (even use ETH_MAX_MTU). We may need a method to notify
> >>>>>>>>>>>> the device about the mtu in this case which is not supported by virtio now.
> >>>>>>>>>>> Note this is not really a XDP specific problem. The guest can change the MTU
> >>>>>>>>>>> after init time even without XDP which I assume should ideally result in a
> >>>>>>>>>>> notification if the MTU is negotiated.
> >>>>>>>>>> Yes, Michael, do you think we need add some mechanism to notify host about
> >>>>>>>>>> MTU change in this case?
> >>>>>>>>>>
> >>>>>>>>>> Thanks
> >>>>>>>>> Why does host care?
> >>>>>>>>>
> >>>>>>>> Well the guest will drop packets after mtu has been reduced.
> >>>>>>> I didn't know. What place in code does this?
> >>>>>>>
> >>>>>> hmm in many of the drivers it is convention to use the mtu to set the rx
> >>>>>> buffer sizes and a receive side max length filter. For example in the Intel
> >>>>>> drivers if a packet with length greater than MTU + some headroom is received we
> >>>>>> drop it. I guess in the networking stack RX path though nothing forces this and
> >>>>>> virtio doesn't have any code to drop packets on rx size.
> >>>>>>
> >>>>>> In virtio I don't see any existing case currently. In the XDP case though we
> >>>>>> need to ensure packets fit in a page for the time being which is why I was
> >>>>>> looking at this code and generated this patch.
> >>>>> I'd say just look at the hardware max mtu. Ignore the configured mtu.
> >>>>>
> >>>>>
> >>>>
> >>>> Does this work for small buffers consider it always allocate skb with size
> >>>> of GOOD_PACKET_LEN?
> >>>
> >>> Spec says hardware won't send in packets > max mtu in config space.
> >>>
> >>>> I think in any case, we should limit max_mtu to
> >>>> GOOD_PACKET_LEN for small buffers.
> >>>>
> >>>> Thanks
> >>>
> >>> XDP seems to have a bunch of weird restrictions, I just
> >>> do not like it that the logic spills out to all drivers.
> >>> What if someone decides to extend it to two pages in the future?
> >>> Recode it all in all drivers ...
> >>>
> >>> Why can't net core enforce mtu?
> >>>
> >>
> >> OK I agree I'll put most the logic in rtnetlink.c when the program is added
> >> or removed.
> >>
> >> But, I'm looking at the non-XDP receive_small path now and wondering how does
> >> multiple buffer receives work (e.g. packet larger than GOOD_PACKET_LEN?)
> >
> > I don't understand the question. Look at add_recvbuf_small,
> > it adds a tiny buffer for head and then the skb.
> >
>
> Specifically this seems to fail with mergeable buffers disabled
>
> On the host:
>
> # ip link set dev tap0 mtu 9000
> # ping 22.2 -s 2048
>
> On the guest:
>
> # insmod ./drivers/net/virtio_net.ko
> # ip link set dev eth0 mtu 9000
Why would it work? You are sending a packet larger than ethernet MTU.
> With mergeable buffers enabled no problems it works as I expect at least.
We don't expect to get these packets but
mergeable is able to process them anyway.
It's an accident :)
>
> >
> >> I think
> >> this is what Jason is looking at as well? The mergeable case clearly looks at
> >> num_bufs in the descriptor to construct multi-buffer packets but nothing like
> >> that exists in the small_receive path as best I can tell.
> >>
> >> .John
> >
> > There's always a single buffer there.
> > BTW it was always a legacy path but if it's now important for people we
> > should probably check ANY_LAYOUT and put header linearly with the packet
> > if there.
> >
^ permalink raw reply
* Re: [PATCH] vhost: scsi: constify target_core_fabric_ops structures
From: Michael S. Tsirkin @ 2017-01-10 5:11 UTC (permalink / raw)
To: Bhumika Goyal; +Cc: kvm, netdev, linux-kernel, virtualization, julia.lawall
In-Reply-To: <1483975262-1260-1-git-send-email-bhumirks@gmail.com>
On Mon, Jan 09, 2017 at 08:51:02PM +0530, Bhumika Goyal wrote:
> Declare target_core_fabric_ops strucrues as const as they are only
> passed as an argument to the functions target_register_template and
> target_unregister_template. The arguments are of type const struct
> target_core_fabric_ops *, so target_core_fabric_ops structures having
> this property can be declared const.
> Done using Coccinelle:
>
> @r disable optional_qualifier@
> identifier i;
> position p;
> @@
> static struct target_core_fabric_ops i@p={...};
>
> @ok@
> position p;
> identifier r.i;
> @@
> (
> target_register_template(&i@p)
> |
> target_unregister_template(&i@p)
> )
> @bad@
> position p!={r.p,ok.p};
> identifier r.i;
> @@
> i@p
>
> @depends on !bad disable optional_qualifier@
> identifier r.i;
> @@
> +const
> struct target_core_fabric_ops i;
>
> File size before: drivers/vhost/scsi.o
> text data bss dec hex filename
> 18063 2985 40 21088 5260 drivers/vhost/scsi.o
>
> File size after: drivers/vhost/scsi.o
> text data bss dec hex filename
> 18479 2601 40 21120 5280 drivers/vhost/scsi.o
What are these numbers trying to prove?
> Signed-off-by: Bhumika Goyal <bhumirks@gmail.com>
> ---
> drivers/vhost/scsi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
> index 253310c..620366d 100644
> --- a/drivers/vhost/scsi.c
> +++ b/drivers/vhost/scsi.c
> @@ -2087,7 +2087,7 @@ static void vhost_scsi_drop_tport(struct se_wwn *wwn)
> NULL,
> };
>
> -static struct target_core_fabric_ops vhost_scsi_ops = {
> +static const struct target_core_fabric_ops vhost_scsi_ops = {
> .module = THIS_MODULE,
> .name = "vhost",
> .get_fabric_name = vhost_scsi_get_fabric_name,
If it can be const it probably should ...
> --
> 1.9.1
^ permalink raw reply
* Re: [PATCH RFC 3/4] dt-bindings: correct marvell orion MDIO binding document
From: Rob Herring @ 2017-01-10 5:35 UTC (permalink / raw)
To: Russell King
Cc: Thomas Petazzoni, Andrew Lunn, Jason Cooper, Gregory Clement,
Mark Rutland, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Marcin Wojtas, Sebastian Hesselbarth,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <E1cPpAk-0005uJ-TM-eh5Bv4kxaXIk46pC+1QYvQNdhmdF6hFW@public.gmane.org>
On Sat, Jan 07, 2017 at 11:28:30AM +0000, Russell King wrote:
> Correct the Marvell Orion MDIO binding document to properly reflect the
> cases where an interrupt is present. Augment the examples to show this.
>
> Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
> ---
> .../devicetree/bindings/net/marvell-orion-mdio.txt | 17 +++++++++++++++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* pull-request: wireless-drivers 2017-01-10
From: Kalle Valo @ 2017-01-10 6:18 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
Hi Dave,
here's the pull request with the important rtlwifi fix, more info in the
tag below.
During the long weekend we had here I finally updated Ubuntu on my
workstation and git was updated along that. If you see anything funny or
problems in my pull request due to the upgrade, please let me know. The
upgrade might have broken something, at least git-request-pull needs to
be now called differently.
Kalle
The following changes since commit f5a0aab84b74de68523599817569c057c7ac1622:
net: ipv4: dst for local input routes should use l3mdev if relevant (2016-12-29 22:27:23 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers.git tags/wireless-drivers-for-davem-2017-01-10
for you to fetch changes up to 60f59ce0278557f7896d5158ae6d12a4855a72cc:
rtlwifi: rtl_usb: Fix missing entry in USB driver's private data (2016-12-30 15:38:13 +0200)
----------------------------------------------------------------
wireless-drivers fixes for 4.10
Only two fixes at this time. The rtlwifi fix is an important one as it
fixes a reported oops and Linus was already asking about it. The
orinoco fix is not tested on a real device, because it's old legacy
hardware and hardly no-one use it, but it should fix a (theoretical)
issue with VMAP_STACK.
----------------------------------------------------------------
Andrew Lutomirski (1):
orinoco: Use shash instead of ahash for MIC calculations
Larry Finger (1):
rtlwifi: rtl_usb: Fix missing entry in USB driver's private data
drivers/net/wireless/intersil/orinoco/mic.c | 44 +++++++++++++++----------
drivers/net/wireless/intersil/orinoco/mic.h | 3 +-
drivers/net/wireless/intersil/orinoco/orinoco.h | 4 +--
drivers/net/wireless/realtek/rtlwifi/usb.c | 1 +
4 files changed, 31 insertions(+), 21 deletions(-)
^ permalink raw reply
* Re: [PATCH v2 03/13] net: ethernet: aquantia: Add ring support code
From: Stephen Hemminger @ 2017-01-10 6:34 UTC (permalink / raw)
To: Alexander Loktionov
Cc: netdev, David VomLehn, Simon Edelhaus, Dmitrii Tarakanov,
Pavel Belous
In-Reply-To: <6dfadde2e1fe39b46d814c83fb7460566e860095.1483999588.git.vomlehn@texas.net>
On Mon, 9 Jan 2017 14:16:01 -0800
Alexander Loktionov <Alexander.Loktionov@aquantia.com> wrote:
> ++self->stats.rx_packets;
> + ++ndev->stats.rx_packets;
> + ndev->stats.rx_bytes += buff->len;
Why keep two sets of statistics (self->stats and ndev->stats); seems redundant.
Could also use per-cpu network stats pcpu_sw_netstats
You could also optimize by doing only one addition of ndev->stats after processing
several packets.
> + skb = netdev_alloc_skb(ndev, ETH_HLEN);
> + skb_put(skb, ETH_HLEN);
> + memcpy(skb->data, page_address(buff->page), ETH_HLEN);
Why not use build_skb() here?
^ permalink raw reply
* Re: [for-next V3 00/10][pull request] Mellanox 100G mlx5 4K UAR support
From: Leon Romanovsky @ 2017-01-10 6:50 UTC (permalink / raw)
To: Doug Ledford
Cc: Saeed Mahameed, David S. Miller, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, Eli Cohen, Matan Barak
In-Reply-To: <1484024006.2149.11.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 4474 bytes --]
On Mon, Jan 09, 2017 at 11:53:26PM -0500, Doug Ledford wrote:
> On Mon, 2017-01-09 at 21:00 +0200, Saeed Mahameed wrote:
> > Hi Dave and Doug,
> >
> > Following the mlx5-odp submission, you can find here the 2nd mlx5
> > submission for 4.11 as a pull-request including mlx5 4K UAR support
> > from
> > Eli Cohen (details below). For you Doug, this pull request will
> > provide
> > you with both mlx5 odp and mlx5 4k UAR since it is based on Dave's
> > net-next mlx5-odp merge commit.
> >
> > v1->v2:
> > - Removed 64BIT arch dependency.
> > v2->v3:
> > - Removed extra space.
> >
> > Thank you,
> > Saeed.
> >
> > The following changes since commit
> > 525dfa2cdce4f5ab76251b5e57ebabf4f2dfc40c:
> >
> > Merge branch 'mlx5-odp' (2017-01-02 15:51:21 -0500)
>
> This base commit looks harmless enough, but since it's likely just a
> commit in your tree, it isn't really a clear indicator of how you set
> this tree up....
>
> > are available in the git repository at:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux.git
> > tags/mlx5-4kuar-for-4.11
> >
> > for you to fetch changes up to
> > f502d834950a28e02651bb7e2cc7111ddd352644:
> >
> > net/mlx5: Activate support for 4K UARs (2017-01-09 20:25:10 +0200)
>
> But once I pulled this, it became clear you guys based your tree on a
> net-next starting point. You need to make that clear in the beginning.
> And unless you can't avoid it, don't do it. I don't like having to
> pull in Dave's net-next before I pull your code because it means I
> can't submit my pull request to Linus during the merge window as a
> single pull request, I have to split it up to be the stuff that is
> based on net-next and the stuff based on my own next area.
>
> >
> > ----------------------------------------------------------------
> > Eli Cohen (10):
> > IB/mlx5: Fix kernel to user leak prevention logic
> > IB/mlx5: Fix error handling order in create_kernel_qp
> > mlx5: Fix naming convention with respect to UARs
> > IB/mlx5: Fix retrieval of index to first hi class bfreg
> > net/mlx5: Introduce blue flame register allocator
> > net/mlx5: Add interface to get reference to a UAR
> > IB/mlx5: Use blue flame register allocator in mlx5_ib
> > IB/mlx5: Allow future extension of libmlx5 input data
> > IB/mlx5: Support 4k UAR for libmlx5
> > net/mlx5: Activate support for 4K UARs
> >
> > drivers/infiniband/hw/mlx5/cq.c | 10 +-
> > drivers/infiniband/hw/mlx5/main.c | 278 ++++++++++-
> > -----
> > drivers/infiniband/hw/mlx5/mlx5_ib.h | 32 +-
> > drivers/infiniband/hw/mlx5/qp.c | 290 +++++++--
> > --------
> > drivers/net/ethernet/mellanox/mlx5/core/cq.c | 2 +
> > drivers/net/ethernet/mellanox/mlx5/core/en.h | 11 +-
> > .../net/ethernet/mellanox/mlx5/core/en_common.c | 12 +-
> > drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 21 +-
> > drivers/net/ethernet/mellanox/mlx5/core/eq.c | 14 +-
> > drivers/net/ethernet/mellanox/mlx5/core/main.c | 26 +-
> > drivers/net/ethernet/mellanox/mlx5/core/uar.c | 351
> > +++++++++++++--------
> > include/linux/mlx5/cq.h | 5 +-
> > include/linux/mlx5/device.h | 23 +-
> > include/linux/mlx5/doorbell.h | 6 +-
> > include/linux/mlx5/driver.h | 81 ++---
> > include/linux/mlx5/mlx5_ifc.h | 7 +-
> > include/uapi/rdma/mlx5-abi.h | 19 +-
> > 17 files changed, 672 insertions(+), 516 deletions(-)
>
> Without going into excruciating detail, this is what I got when I
> pulled your branch:
>
> 273 files changed, 8891 insertions(+), 6637 deletions(-)
> create mode 100644 drivers/net/ethernet/qlogic/qede/qede_filter.c
> create mode 100644 drivers/net/ethernet/qlogic/qede/qede_fp.c
>
> Please don't do this unless you absolutely have to.
We will do our best to avoid such situations in the future.
This specific pull request was after our mistake with first pull
request, which was sent as a patch set, instead of pull request.
>
> --
> Doug Ledford <dledford-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> GPG KeyID: B826A3330E572FDD
>
> Key fingerprint = AE6B 1BDA 122B 23B4 265B 1274 B826 A333 0E57 2FDD
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [Open-FCoE] [PATCH RFC 2/5] qedf: Add QLogic FastLinQ offload FCoE driver framework.
From: Hannes Reinecke @ 2017-01-10 6:56 UTC (permalink / raw)
To: Chad Dupuis
Cc: martin.petersen, fcoe-devel, netdev, QLogic-Storage-Upstream,
linux-scsi, yuval.mintz
In-Reply-To: <alpine.OSX.2.00.1701091141550.1044@administrators-macbook-pro.local>
On 01/09/2017 05:45 PM, Chad Dupuis wrote:
>
> On Wed, 28 Dec 2016, 9:00am -0000, Hannes Reinecke wrote:
>
>> On 12/23/2016 08:17 PM, Dupuis, Chad wrote:
>>> From: "Dupuis, Chad" <chad.dupuis@cavium.com>
>>>
>>> The QLogic FastLinQ Driver for FCoE (qedf) is the FCoE specific module
>>> for 41000 Series Converged Network Adapters by QLogic.
>>>
>>> This patch consists of following changes:
>>> - MAINTAINERS Makefile and Kconfig changes for qedf
>>> - PCI driver registration
>>> - libfc/fcoe host level initialization
>>> - SCSI host template initialization and callbacks
>>> - Debugfs and log level infrastructure
>>> - Link handling
>>> - Firmware interface structures
>>> - QED core module initialization
>>> - Light L2 interface callbacks
>>>
>>> Signed-off-by: Nilesh Javali <nilesh.javali@cavium.com>
>>> Signed-off-by: Manish Rangankar <manish.rangankar@cavium.com>
>>> Signed-off-by: Saurav Kashyap <saurav.kashyap@cavium.com>
>>> Signed-off-by: Chad Dupuis <chad.dupuis@cavium.com>
>>> ---
>>> MAINTAINERS | 6 +
>>> drivers/scsi/Kconfig | 1 +
>>> drivers/scsi/qedf/Kconfig | 11 +
>>> drivers/scsi/qedf/Makefile | 5 +
>>> drivers/scsi/qedf/qedf.h | 555 ++++++
>>> drivers/scsi/qedf/qedf_attr.c | 165 ++
>>> drivers/scsi/qedf/qedf_dbg.c | 192 +++
>>> drivers/scsi/qedf/qedf_dbg.h | 153 ++
>>> drivers/scsi/qedf/qedf_debugfs.c | 472 +++++
>>> drivers/scsi/qedf/qedf_main.c | 3519 ++++++++++++++++++++++++++++++++++++++
>>> drivers/scsi/qedf/qedf_version.h | 15 +
>>> 11 files changed, 5094 insertions(+)
>>> create mode 100644 drivers/scsi/qedf/Kconfig
>>> create mode 100644 drivers/scsi/qedf/Makefile
>>> create mode 100644 drivers/scsi/qedf/qedf.h
>>> create mode 100644 drivers/scsi/qedf/qedf_attr.c
>>> create mode 100644 drivers/scsi/qedf/qedf_dbg.c
>>> create mode 100644 drivers/scsi/qedf/qedf_dbg.h
>>> create mode 100644 drivers/scsi/qedf/qedf_debugfs.c
>>> create mode 100644 drivers/scsi/qedf/qedf_main.c
>>> create mode 100644 drivers/scsi/qedf/qedf_version.h
>>>
>> [ .. ]
>>> +/* Returns true if we have a valid vlan, false otherwise */
>>> +static bool qedf_initiate_fipvlan_req(struct qedf_ctx *qedf)
>>> +{
>>> + int rc;
>>> +
>>> + if (atomic_read(&qedf->link_state) != QEDF_LINK_UP) {
>>> + QEDF_ERR(&(qedf->dbg_ctx), "Link not up.\n");
>>> + return false;
>>> + }
>>> +
>>> + while (qedf->fipvlan_retries--) {
>>> + if (qedf->vlan_id > 0)
>>> + return true;
>> Some weird FCoE bridges (most notably HP VirtualConnect) return a VLAN
>> ID of '0'. Shouldn't you rather test for '>= 0' here?
>
> Will look into this but isn't a VLAN ID of 0 not valid?
>
Well, a VLAN ID of '0' indicates no VLAN at all but rather use the base
interface.
But you still will be seeing a VLAN ID '0' in the FIP VLAN response.
Cheers,
Hannes
--
Dr. Hannes Reinecke Teamlead Storage & Networking
hare@suse.de +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: [PATCH RFC 5/5] qedf: Add FIP request handling
From: Hannes Reinecke @ 2017-01-10 6:58 UTC (permalink / raw)
To: Chad Dupuis
Cc: martin.petersen-QHcLZuEGTsvQT0dZR+AlfA,
linux-scsi-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
yuval.mintz-YGCgFSpz5w/QT0dZR+AlfA,
fcoe-devel-s9riP+hp16TNLxjTenLetw,
QLogic-Storage-Upstream-YGCgFSpz5w/QT0dZR+AlfA
In-Reply-To: <alpine.OSX.2.00.1701091147040.1044-nVgGmETfwnIFUnR/tdpssI0aTaFgKE92ACYyPGjX6YU@public.gmane.org>
On 01/09/2017 05:47 PM, Chad Dupuis wrote:
>
> On Wed, 28 Dec 2016, 9:11am -0000, Hannes Reinecke wrote:
>
>> On 12/23/2016 08:17 PM, Dupuis, Chad wrote:
>>> From: "Dupuis, Chad" <chad.dupuis-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
>>>
>>> This patch adds handling for FIP requests and responses that are handled by
>>> the driver itself and not by libfcoe.
>>>
>>> Signed-off-by: Nilesh Javali <nilesh.javali-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
>>> Signed-off-by: Manish Rangankar <manish.rangankar-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
>>> Signed-off-by: Saurav Kashyap <saurav.kashyap-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
>>> Signed-off-by: Chad Dupuis <chad.dupuis-YGCgFSpz5w/QT0dZR+AlfA@public.gmane.org>
>>> ---
>>> drivers/scsi/qedf/qedf_fip.c | 267 +++++++++++++++++++++++++++++++++++++++++++
>>> 1 file changed, 267 insertions(+)
>>> create mode 100644 drivers/scsi/qedf/qedf_fip.c
>>>
>>> diff --git a/drivers/scsi/qedf/qedf_fip.c b/drivers/scsi/qedf/qedf_fip.c
>>> new file mode 100644
>>> index 0000000..4f185c6
>>> --- /dev/null
>>> +++ b/drivers/scsi/qedf/qedf_fip.c
>>> @@ -0,0 +1,267 @@
>>> +/*
>>> + * QLogic FCoE Offload Driver
>>> + * Copyright (c) 2016 Cavium Inc.
>>> + *
>>> + * This software is available under the terms of the GNU General Public License
>>> + * (GPL) Version 2, available from the file COPYING in the main directory of
>>> + * this source tree.
>>> + */
>>> +#include <linux/if_ether.h>
>>> +#include <linux/if_vlan.h>
>>> +#include "qedf.h"
>>> +
>>> +extern const struct qed_fcoe_ops *qed_ops;
>>> +/*
>>> + * FIP VLAN functions that will eventually move to libfcoe.
>>> + */
>>> +
>>> +void qedf_fcoe_send_vlan_req(struct qedf_ctx *qedf)
>>> +{
>>> + struct sk_buff *skb;
>>> + char *eth_fr;
>>> + int fr_len;
>>> + struct fip_vlan *vlan;
>>> +#define MY_FIP_ALL_FCF_MACS ((__u8[6]) { 1, 0x10, 0x18, 1, 0, 2 })
>>> + static u8 my_fcoe_all_fcfs[ETH_ALEN] = MY_FIP_ALL_FCF_MACS;
>>
>> Do you support VN2VN, too?
>
> Not currently, no.
>
Ah.
Too bad. Any plans for it?
It certainly eases up P2P setups for FCoE...
Cheers,
Hannes
--
Dr. Hannes Reinecke Teamlead Storage & Networking
hare-l3A5Bk7waGM@public.gmane.org +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* Re: [RFC v2 00/10] HFI Virtual Network Interface Controller (VNIC)
From: Leon Romanovsky @ 2017-01-10 8:14 UTC (permalink / raw)
To: Vishwanathapura, Niranjana
Cc: Doug Ledford, ira.weiny, Jeff Kirsher, David S. Miller,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
dennis.dalessandro-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <20170110033954.GA53664-wPcXA7LoDC+1XWohqUldA0EOCMrvLtNR@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2394 bytes --]
On Mon, Jan 09, 2017 at 07:39:54PM -0800, Vishwanathapura, Niranjana wrote:
> On Mon, Jan 09, 2017 at 09:51:04AM +0200, Leon Romanovsky wrote:
> > On Thu, Dec 15, 2016 at 11:28:06AM -0500, Doug Ledford wrote:
> > > On 12/15/2016 9:52 AM, ira.weiny wrote:
> > >
> > > 2) With more than 60% of the code being MAD related, and another
> > > significant chunk being hfi related, and only a minor bit (20% maybe?)
> > > being net related,
> >
> > Hi Doug and Ira,
> >
> > I may admit that I didn't read the code very deep, but from brief
> > overview, I didn't find support for the claim the "60% code is MAD related".
> > It looks like the opposite thing will be more accurate.
> >
> > Can you help me to understand this claim? How did you come to this
> > conclusion?
> >
> > Thanks
>
> Hi Leon,
>
> Here is the breakdown of patches based on functionality.
Hi Niranjana,
Thank you for breakdown, it helped a lot.
> In this series, patches #3..#8 compose hfi_vnic driver. In that, patches #4,
> #7 and #8 are MAD focused (interfacing with MAD agent and handling MAD
> packets).
Patch #3 is net device with all goodies from net stack.
https://patchwork.kernel.org/patch/9475639/
Patch #4 has one IB MAD related struct, all other things are specific to
OFA and HFI declarations.
https://patchwork.kernel.org/patch/9475653/
Patch #7 continues to implement agnostic to IB MAD net device.
https://patchwork.kernel.org/patch/9475641/
Patch #8 is without doubts, MAD related.
https://patchwork.kernel.org/patch/9475651/
Let's put aside patch #8, in such case, the proposed code won't need IB/core at
all and will look exactly like many other net drivers which encapsulate/decapsulate
packets.
> Patch #6 and half of #3 (_encap.c/h) are OPA encapsulation related. Patch #5
> is netdev statistic related (which includes statistics MAD definitions).
> So, only part of patch #3 (_netdev.c and _ethtool.c) deals with interfacing
> with netstack.
> Those percentage numbers are based on actual lines of code in these patches
> (files).
>
> We are also looking into Jason’s suggestion to make hfi_vnic interface to
> the bottom driver a generic interface. This will include moving some of the
> netstack interfacing to the bottom hfi1 driver.
Great, do you have rough estimation when will it be posted on the ML?
Thanks
>
> Niranjana
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH net] net: socket: Make unnecessarily global sockfs_setattr() static
From: Tobias Klauser @ 2017-01-10 8:30 UTC (permalink / raw)
To: netdev; +Cc: David S. Miller, Lorenzo Colitti
Make sockfs_setattr() static as it is not used outside of net/socket.c
This fixes the following GCC warning:
net/socket.c:534:5: warning: no previous prototype for ‘sockfs_setattr’ [-Wmissing-prototypes]
Fixes: 86741ec25462 ("net: core: Add a UID field to struct sock.")
Cc: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: Tobias Klauser <tklauser@distanz.ch>
---
net/socket.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/socket.c b/net/socket.c
index 009dd12ab7f3..727dfd96da07 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -531,7 +531,7 @@ static ssize_t sockfs_listxattr(struct dentry *dentry, char *buffer,
return used;
}
-int sockfs_setattr(struct dentry *dentry, struct iattr *iattr)
+static int sockfs_setattr(struct dentry *dentry, struct iattr *iattr)
{
int err = simple_setattr(dentry, iattr);
--
2.11.0
^ permalink raw reply related
* Re: [PATCH net] net: socket: Make unnecessarily global sockfs_setattr() static
From: Lorenzo Colitti @ 2017-01-10 8:32 UTC (permalink / raw)
To: Tobias Klauser; +Cc: netdev@vger.kernel.org, David S. Miller
In-Reply-To: <20170110083051.753-1-tklauser@distanz.ch>
On Tue, Jan 10, 2017 at 5:30 PM, Tobias Klauser <tklauser@distanz.ch> wrote:
> -int sockfs_setattr(struct dentry *dentry, struct iattr *iattr)
> +static int sockfs_setattr(struct dentry *dentry, struct iattr *iattr)
Acked-by: Lorenzo Colitti <lorenzo@google.com>
^ permalink raw reply
* Re: [next-queue v3 PATCH 6/7] i40e: Add support for exposing VF port statistics via VFPR netdev on the host.
From: kbuild test robot @ 2017-01-10 8:37 UTC (permalink / raw)
To: Sridhar Samudrala
Cc: kbuild-all, alexander.h.duyck, john.r.fastabend, anjali.singhai,
jakub.kicinski, davem, scott.d.peterson, gerlitz.or, jiri,
intel-wired-lan, netdev
In-Reply-To: <1484009990-3018-7-git-send-email-sridhar.samudrala@intel.com>
[-- Attachment #1: Type: text/plain, Size: 1768 bytes --]
Hi Sridhar,
[auto build test ERROR on jkirsher-next-queue/dev-queue]
[cannot apply to v4.10-rc3 next-20170110]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Sridhar-Samudrala/i40e-Introduce-devlink-interface/20170110-140906
base: https://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git dev-queue
config: x86_64-rhel (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
>> drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:1163:28: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
.ndo_get_stats64 = i40e_vfpr_netdev_get_stats64,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c:1163:28: note: (near initialization for 'i40e_vfpr_netdev_ops.ndo_get_stats64')
cc1: some warnings being treated as errors
vim +1163 drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
1157 }
1158
1159 static const struct net_device_ops i40e_vfpr_netdev_ops = {
1160 .ndo_open = i40e_vfpr_netdev_open,
1161 .ndo_stop = i40e_vfpr_netdev_stop,
1162 .ndo_start_xmit = i40e_vfpr_netdev_start_xmit,
> 1163 .ndo_get_stats64 = i40e_vfpr_netdev_get_stats64,
1164 .ndo_has_offload_stats = i40e_vfpr_netdev_has_offload_stats,
1165 .ndo_get_offload_stats = i40e_vfpr_netdev_get_offload_stats,
1166 };
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 38277 bytes --]
^ permalink raw reply
* Re: [PATCH net v2 5/5] net: qcom/emac: fix of_node and phydev leaks
From: Johan Hovold @ 2017-01-10 8:43 UTC (permalink / raw)
To: Timur Tabi
Cc: Johan Hovold, David S. Miller, Florian Fainelli, Madalin Bucur,
Andrew Lunn, Vivien Didelot, netdev, linux-kernel
In-Reply-To: <650c00e9-cf02-1764-5065-86f6c06817f3@codeaurora.org>
On Mon, Jan 09, 2017 at 01:49:53PM -0600, Timur Tabi wrote:
> On 11/24/2016 12:21 PM, Johan Hovold wrote:
> > + if (!has_acpi_companion(&pdev->dev))
> > + put_device(&adpt->phydev->mdio.dev);
>
> I was wondering if, instead of calling put_device() only on non-ACPI systems,
> would it be better if on an ACPI system I called get_device() manually? That
> is, some thing like this:
>
> int emac_phy_config(struct platform_device *pdev, struct emac_adapter *adpt)
> {
> ...
> if (has_acpi_companion(&pdev->dev)) {
> ...
> get_device(&mii_bus->dev);
> } else {
> ...
Yeah, that's better.
Thanks,
Johan
^ permalink raw reply
* Re: [PATCH] net: qcom/emac: grab a reference to the phydev on ACPI systems
From: Johan Hovold @ 2017-01-10 8:45 UTC (permalink / raw)
To: Timur Tabi; +Cc: David Miller, johan, netdev
In-Reply-To: <1484005926-26673-1-git-send-email-timur@codeaurora.org>
On Mon, Jan 09, 2017 at 05:52:06PM -0600, Timur Tabi wrote:
> Commit 6ffe1c4cd0a7 ("net: qcom/emac: fix of_node and phydev leaks")
> fixed the problem with reference leaks on phydev, but the fix is
> device-tree specific. When the driver unloads, the reference is
> dropped only on DT systems.
>
> Instead, it's cleaner if up grab an reference on ACPI systems.
> When the driver unloads, we can drop the reference without having
> to check whether we're on a DT system.
>
> Signed-off-by: Timur Tabi <timur@codeaurora.org>
> ---
> drivers/net/ethernet/qualcomm/emac/emac-phy.c | 6 ++++++
> drivers/net/ethernet/qualcomm/emac/emac.c | 6 ++----
> 2 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/qualcomm/emac/emac-phy.c b/drivers/net/ethernet/qualcomm/emac/emac-phy.c
> index 99a14df..af485f1 100644
> --- a/drivers/net/ethernet/qualcomm/emac/emac-phy.c
> +++ b/drivers/net/ethernet/qualcomm/emac/emac-phy.c
> @@ -201,6 +201,12 @@ int emac_phy_config(struct platform_device *pdev, struct emac_adapter *adpt)
> else
> adpt->phydev = mdiobus_get_phy(mii_bus, phy_addr);
>
> + /* of_phy_find_device() claims a reference to the phydev,
> + * so we do that here manually as well. When the driver
> + * unloads, it can unilaterally drops the reference
> + * without worrying about ACPI vs DT.
> + */
> + get_device(&adpt->phydev->mdio.dev);
But you cannot do this unconditionally as adpt->phydev can be NULL here.
Looks good to me otherwise.
Thanks,
Johan
^ permalink raw reply
* [PATCH net 0/2] r8152: fix autosuspend issue
From: Hayes Wang @ 2017-01-10 9:04 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
Avoid rx is split into two parts when runtime suspend occurs.
Hayes Wang (2):
r8152: split rtl8152_suspend function
r8152: fix rx issue for runtime suspend
drivers/net/usb/r8152.c | 80 +++++++++++++++++++++++++++++++++++++++----------
1 file changed, 64 insertions(+), 16 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH net 1/2] r8152: split rtl8152_suspend function
From: Hayes Wang @ 2017-01-10 9:04 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: nic_swsd-Rasf1IRRPZFBDgjK7y7TUQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Hayes Wang
In-Reply-To: <1394712342-15778-229-Taiwan-albertk-Rasf1IRRPZFBDgjK7y7TUQ@public.gmane.org>
Split rtl8152_suspend() into rtl8152_system_suspend() and
rtl8152_rumtime_suspend().
Signed-off-by: Hayes Wang <hayeswang-Rasf1IRRPZFBDgjK7y7TUQ@public.gmane.org>
---
drivers/net/usb/r8152.c | 57 ++++++++++++++++++++++++++++++++++---------------
1 file changed, 40 insertions(+), 17 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 7dc6122..c5e6d88 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3576,39 +3576,62 @@ static bool delay_autosuspend(struct r8152 *tp)
return false;
}
-static int rtl8152_suspend(struct usb_interface *intf, pm_message_t message)
+static int rtl8152_rumtime_suspend(struct r8152 *tp)
{
- struct r8152 *tp = usb_get_intfdata(intf);
struct net_device *netdev = tp->netdev;
int ret = 0;
- mutex_lock(&tp->control);
-
- if (PMSG_IS_AUTO(message)) {
- if (netif_running(netdev) && delay_autosuspend(tp)) {
+ if (netif_running(netdev) && test_bit(WORK_ENABLE, &tp->flags)) {
+ if (delay_autosuspend(tp)) {
ret = -EBUSY;
goto out1;
}
- set_bit(SELECTIVE_SUSPEND, &tp->flags);
- } else {
- netif_device_detach(netdev);
+ clear_bit(WORK_ENABLE, &tp->flags);
+ usb_kill_urb(tp->intr_urb);
+ napi_disable(&tp->napi);
+ rtl_stop_rx(tp);
+ tp->rtl_ops.autosuspend_en(tp, true);
+ napi_enable(&tp->napi);
}
+ set_bit(SELECTIVE_SUSPEND, &tp->flags);
+
+out1:
+ return ret;
+}
+
+static int rtl8152_system_suspend(struct r8152 *tp)
+{
+ struct net_device *netdev = tp->netdev;
+ int ret = 0;
+
+ netif_device_detach(netdev);
+
if (netif_running(netdev) && test_bit(WORK_ENABLE, &tp->flags)) {
clear_bit(WORK_ENABLE, &tp->flags);
usb_kill_urb(tp->intr_urb);
napi_disable(&tp->napi);
- if (test_bit(SELECTIVE_SUSPEND, &tp->flags)) {
- rtl_stop_rx(tp);
- tp->rtl_ops.autosuspend_en(tp, true);
- } else {
- cancel_delayed_work_sync(&tp->schedule);
- tp->rtl_ops.down(tp);
- }
+ cancel_delayed_work_sync(&tp->schedule);
+ tp->rtl_ops.down(tp);
napi_enable(&tp->napi);
}
-out1:
+
+ return ret;
+}
+
+static int rtl8152_suspend(struct usb_interface *intf, pm_message_t message)
+{
+ struct r8152 *tp = usb_get_intfdata(intf);
+ int ret;
+
+ mutex_lock(&tp->control);
+
+ if (PMSG_IS_AUTO(message))
+ ret = rtl8152_rumtime_suspend(tp);
+ else
+ ret = rtl8152_system_suspend(tp);
+
mutex_unlock(&tp->control);
return ret;
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH net 2/2] r8152: fix rx issue for runtime suspend
From: Hayes Wang @ 2017-01-10 9:04 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: nic_swsd-Rasf1IRRPZFBDgjK7y7TUQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Hayes Wang
In-Reply-To: <1394712342-15778-229-Taiwan-albertk-Rasf1IRRPZFBDgjK7y7TUQ@public.gmane.org>
Pause the rx and make sure the rx fifo is empty when the autosuspend
occurs.
If the rx data comes when the driver is canceling the rx urb, the host
controller would stop getting the data from the device and continue
it after next rx urb is submitted. That is, one continuing data is
split into two different urb buffers. That let the driver take the
data as a rx descriptor, and unexpected behavior happens.
Signed-off-by: Hayes Wang <hayeswang-Rasf1IRRPZFBDgjK7y7TUQ@public.gmane.org>
---
drivers/net/usb/r8152.c | 31 ++++++++++++++++++++++++++++---
1 file changed, 28 insertions(+), 3 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index c5e6d88..be41856 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -3582,17 +3582,42 @@ static int rtl8152_rumtime_suspend(struct r8152 *tp)
int ret = 0;
if (netif_running(netdev) && test_bit(WORK_ENABLE, &tp->flags)) {
+ u32 rcr = 0;
+
if (delay_autosuspend(tp)) {
ret = -EBUSY;
goto out1;
}
+ if (netif_carrier_ok(netdev)) {
+ u32 ocp_data;
+
+ rcr = ocp_read_dword(tp, MCU_TYPE_PLA, PLA_RCR);
+ ocp_data = rcr & ~RCR_ACPT_ALL;
+ ocp_write_dword(tp, MCU_TYPE_PLA, PLA_RCR, ocp_data);
+ rxdy_gated_en(tp, true);
+ ocp_data = ocp_read_byte(tp, MCU_TYPE_PLA,
+ PLA_OOB_CTRL);
+ if (!(ocp_data & RXFIFO_EMPTY)) {
+ rxdy_gated_en(tp, false);
+ ocp_write_dword(tp, MCU_TYPE_PLA, PLA_RCR, rcr);
+ ret = -EBUSY;
+ goto out1;
+ }
+ }
+
clear_bit(WORK_ENABLE, &tp->flags);
usb_kill_urb(tp->intr_urb);
- napi_disable(&tp->napi);
- rtl_stop_rx(tp);
+
tp->rtl_ops.autosuspend_en(tp, true);
- napi_enable(&tp->napi);
+
+ if (netif_carrier_ok(netdev)) {
+ napi_disable(&tp->napi);
+ rtl_stop_rx(tp);
+ rxdy_gated_en(tp, false);
+ ocp_write_dword(tp, MCU_TYPE_PLA, PLA_RCR, rcr);
+ napi_enable(&tp->napi);
+ }
}
set_bit(SELECTIVE_SUSPEND, &tp->flags);
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH net-next v2] net: dsa: make "label" property optional for dsa2
From: Jiri Pirko @ 2017-01-10 9:55 UTC (permalink / raw)
To: Florian Fainelli
Cc: Vivien Didelot, netdev, linux-kernel, kernel, David S. Miller,
Andrew Lunn, Uwe Kleine-König, Andrey Smirnov
In-Reply-To: <3897e83d-83a6-7bb1-311d-ae228390f757@gmail.com>
Mon, Jan 09, 2017 at 07:06:39PM CET, f.fainelli@gmail.com wrote:
>On 01/09/2017 09:58 AM, Jiri Pirko wrote:
>> Mon, Jan 09, 2017 at 06:42:07PM CET, f.fainelli@gmail.com wrote:
>>> On 01/09/2017 08:06 AM, Jiri Pirko wrote:
>>>> Mon, Jan 09, 2017 at 04:45:33PM CET, vivien.didelot@savoirfairelinux.com wrote:
>>>>> Hi Jiri,
>>>>>
>>>>> Jiri Pirko <jiri@resnulli.us> writes:
>>>>>
>>>>>>> Extra question: shouldn't phys_port_{id,name} be switchdev attributes in
>>>>>>
>>>>>> Again, phys_port_id has nothing to do with switches. Should be removed
>>>>>> from dsa because its use there is incorrect.
>>>>>
>>>>> Florian, since 3a543ef just got in, can it be reverted?
>>>>
>>>> Yes, please revert it. It is only in net-next.
>>>
>>> Maybe the use case can be understood before reverting the change. How do
>>> we actually the physical port number of an Ethernet switch per-port
>>> network device? The name is not enough, because there are plenty of
>>> cases where we need to manipulate a physical port number (be it just for
>>> informational purposes).
>>
>> Like what?
>
>Specifying the physical port number (and derive a queue number
>eventually) for some ethtool (e.g: rxnfc)/tc (queue mapping) operations
>where there is an action/queue/port destination argument that gets
>programmed into the hardware.
Could you point me to a real example? User command?
>
>You already have the originating port number from the interface you call
>the method against, but you also need the destination port number since
>that is what the HW understands.
This is internal to kernel? I fail to understand what you mean exactly.
>
>Aside from that, it is useful for allowing interface naming in user
>space if you don't want to use labels.
>
>>
>> Why the name is not enough? This is something propagated to userspace
>> and never used internally in kernel.
>
>Because the name is not reflective of the port number in some switches.
>In my case for instance, we have 5 ports that are named after the
>entities they connect to (an integrated Gigabit PHY, two RGMII pads, one
>MoCA interface, and the CPU)
>
Again, I'm missing why you need a portnumber as a Integer to userspace.
>From driver, you can expose phys_port_name:
>0 -> gphy
"p0" or "gphy"
>1 -> rgmii_1
"p1" or "rgmii_1"
>2 -> rgmii_2
...
>7 -> moca
>8 -> cpu
>
>>
>> Btw, ndo_get_phys_port_id does not give you number, but arbitrary binary.
>
>It's not entirely arbitrary for DSA switches since the port number is
>stored in an u8 whose value is the port number in hexadecimal (as shown
>by sysfs at least).
In mlxsw, we also have port number stored in u8. It is used to
communicate with hw of course. But outside the driver, this is exposed
as phys_port_name "pX".
^ permalink raw reply
* Re: linux-next: manual merge of the y2038 tree with the net-next tree
From: Arnd Bergmann @ 2017-01-10 10:06 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Miller, Networking, linux-next, linux-kernel, David Howells,
Tina Ruchandani
In-Reply-To: <20170110135201.2a62a4d9@canb.auug.org.au>
Hmm, I thought I had removed that commit when you asked me about it
last week. I've done it now, the conflict should be gone tomorrow.
On Tue, Jan 10, 2017 at 3:52 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Arnd,
>
> Today's linux-next merge of the y2038 tree got a conflict in:
>
> fs/afs/main.c
>
> between commit:
>
> 8e8d7f13b6d5 ("afs: Add some tracepoints")
>
> from the net-next tree and commit:
>
> 549eb7b22e24 ("AFS: Correctly use 64-bit time for UUID")
>
> from the y2038 tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc fs/afs/main.c
> index f8188feb03ad,129ff432391c..000000000000
> --- a/fs/afs/main.c
> +++ b/fs/afs/main.c
> @@@ -14,8 -14,7 +14,9 @@@
> #include <linux/init.h>
> #include <linux/completion.h>
> #include <linux/sched.h>
> +#include <linux/random.h>
> +#define CREATE_TRACE_POINTS
> + #include <linux/ktime.h>
> #include "internal.h"
>
> MODULE_DESCRIPTION("AFS Client File System");
^ 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