* Re: [PATCH V2 net-next 1/6] virtio: Add support for SCTP checksum offloading
From: Michael S. Tsirkin @ 2018-05-02 14:21 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: Vladislav Yasevich, netdev, linux-sctp, virtualization,
virtio-dev, jasowang, nhorman, Vladislav Yasevich
In-Reply-To: <20180502141413.GD5105@localhost.localdomain>
On Wed, May 02, 2018 at 11:14:13AM -0300, Marcelo Ricardo Leitner wrote:
> On Wed, May 02, 2018 at 06:16:45AM +0300, Michael S. Tsirkin wrote:
> > On Tue, May 01, 2018 at 10:07:34PM -0400, Vladislav Yasevich wrote:
> > > To support SCTP checksum offloading, we need to add a new feature
> > > to virtio_net, so we can negotiate support between the hypervisor
> > > and the guest.
> > > The HOST feature bit signifies offloading support for transmit and
> > > enables device offload features.
> > > The GUEST feature bit signifies offloading support of recieve and
> > > is currently only used by the driver in case of xdp.
> > >
> > > That patch also adds an addition virtio_net header flag which
> > > mirrors the skb->csum_not_inet flag. This flags is used to indicate
> > > that is this an SCTP packet that needs its checksum computed by the
> > > lower layer. In this case, the lower layer is the host hypervisor or
> > > possibly HW nic that supporst CRC32c offload.
> > >
> > > In the case that GUEST feature bit is flag, it will be possible to
> > > receive a virtio_net header with this bit set, which will set the
> > > corresponding skb bit. SCTP protocol will be updated to correctly
> > > deal with it.
> > >
> > > Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
> > > ---
> > > drivers/net/virtio_net.c | 14 +++++++++++++-
> > > include/linux/virtio_net.h | 6 ++++++
> > > include/uapi/linux/virtio_net.h | 5 +++++
> > > 3 files changed, 24 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > > index 7b187ec..34af280 100644
> > > --- a/drivers/net/virtio_net.c
> > > +++ b/drivers/net/virtio_net.c
> > > @@ -2148,6 +2148,8 @@ static int virtnet_clear_guest_offloads(struct virtnet_info *vi)
> > >
> > > if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_CSUM))
> > > offloads = 1ULL << VIRTIO_NET_F_GUEST_CSUM;
> > > + if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_SCTP_CSUM))
> > > + offloads |= 1ULL << VIRTIO_NET_F_GUEST_SCTP_CSUM;
> > >
> > > return virtnet_set_guest_offloads(vi, offloads);
> > > }
> > > @@ -2160,6 +2162,8 @@ static int virtnet_restore_guest_offloads(struct virtnet_info *vi)
> > > return 0;
> > > if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_CSUM))
> > > offloads |= 1ULL << VIRTIO_NET_F_GUEST_CSUM;
> > > + if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_SCTP_CSUM))
> > > + offloads |= 1ULL << VIRTIO_NET_F_GUEST_SCTP_CSUM;
> > >
> > > return virtnet_set_guest_offloads(vi, offloads);
> > > }
> > > @@ -2724,6 +2728,7 @@ static int virtnet_probe(struct virtio_device *vdev)
> > > /* Do we support "hardware" checksums? */
> > > if (virtio_has_feature(vdev, VIRTIO_NET_F_CSUM)) {
> > > /* This opens up the world of extra features. */
> > > +
> > > dev->hw_features |= NETIF_F_HW_CSUM | NETIF_F_SG;
> > > if (csum)
> > > dev->features |= NETIF_F_HW_CSUM | NETIF_F_SG;
> > > @@ -2746,9 +2751,15 @@ static int virtnet_probe(struct virtio_device *vdev)
> > > dev->features |= dev->hw_features & NETIF_F_ALL_TSO;
> > > /* (!csum && gso) case will be fixed by register_netdev() */
> > > }
> > > +
> > > if (virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_CSUM))
> > > dev->features |= NETIF_F_RXCSUM;
> > >
> > > + if (virtio_has_feature(vdev, VIRTIO_NET_F_HOST_SCTP_CSUM)) {
> > > + dev->hw_features |= NETIF_F_SCTP_CRC;
> > > + dev->features |= NETIF_F_SCTP_CRC;
> > > + }
> > > +
> > > dev->vlan_features = dev->features;
> > >
> > > /* MTU range: 68 - 65535 */
> > > @@ -2962,7 +2973,8 @@ static struct virtio_device_id id_table[] = {
> > > VIRTIO_NET_F_GUEST_ANNOUNCE, VIRTIO_NET_F_MQ, \
> > > VIRTIO_NET_F_CTRL_MAC_ADDR, \
> > > VIRTIO_NET_F_MTU, VIRTIO_NET_F_CTRL_GUEST_OFFLOADS, \
> > > - VIRTIO_NET_F_SPEED_DUPLEX
> > > + VIRTIO_NET_F_SPEED_DUPLEX, \
> > > + VIRTIO_NET_F_HOST_SCTP_CSUM, VIRTIO_NET_F_GUEST_SCTP_CSUM
> > >
> > > static unsigned int features[] = {
> > > VIRTNET_FEATURES,
> > > diff --git a/include/linux/virtio_net.h b/include/linux/virtio_net.h
> > > index f144216..28fffdc 100644
> > > --- a/include/linux/virtio_net.h
> > > +++ b/include/linux/virtio_net.h
> > > @@ -39,6 +39,9 @@ static inline int virtio_net_hdr_to_skb(struct sk_buff *skb,
> > >
> > > if (!skb_partial_csum_set(skb, start, off))
> > > return -EINVAL;
> > > +
> > > + if (hdr->flags & VIRTIO_NET_HDR_F_CSUM_NOT_INET)
> > > + skb->csum_not_inet = 1;
> > > }
> > >
> > > if (hdr->gso_type != VIRTIO_NET_HDR_GSO_NONE) {
> > > @@ -91,6 +94,9 @@ static inline int virtio_net_hdr_from_skb(const struct sk_buff *skb,
> > > skb_checksum_start_offset(skb));
> > > hdr->csum_offset = __cpu_to_virtio16(little_endian,
> > > skb->csum_offset);
> > > +
> > > + if (skb->csum_not_inet)
> > > + hdr->flags |= VIRTIO_NET_HDR_F_CSUM_NOT_INET;
> > > } else if (has_data_valid &&
> > > skb->ip_summed == CHECKSUM_UNNECESSARY) {
> > > hdr->flags = VIRTIO_NET_HDR_F_DATA_VALID;
> > > diff --git a/include/uapi/linux/virtio_net.h b/include/uapi/linux/virtio_net.h
> > > index 5de6ed3..9dfca1a 100644
> > > --- a/include/uapi/linux/virtio_net.h
> > > +++ b/include/uapi/linux/virtio_net.h
> > > @@ -57,6 +57,10 @@
> > > * Steering */
> > > #define VIRTIO_NET_F_CTRL_MAC_ADDR 23 /* Set MAC address */
> > >
> > > +#define VIRTIO_NET_F_GUEST_SCTP_CSUM 61 /* Guest handles SCTP pks w/ partial
> > > + * csum */
> > > +#define VIRTIO_NET_F_HOST_SCTP_CSUM 62 /* HOST handles SCTP pkts w/ partial
> > > + * csum */
> > > #define VIRTIO_NET_F_SPEED_DUPLEX 63 /* Device set linkspeed and duplex */
> > >
> > > #ifndef VIRTIO_NET_NO_LEGACY
> > > @@ -101,6 +105,7 @@ struct virtio_net_config {
> > > struct virtio_net_hdr_v1 {
> > > #define VIRTIO_NET_HDR_F_NEEDS_CSUM 1 /* Use csum_start, csum_offset */
> > > #define VIRTIO_NET_HDR_F_DATA_VALID 2 /* Csum is valid */
> > > +#define VIRTIO_NET_HDR_F_CSUM_NOT_INET 4 /* Checksum is not inet */
> >
> > Both comment and name are not very informative.
> > How about just saying CRC32c ?
>
> csum_not_inet is following the nomenclature used in sk_buff. Initially
> Davide had named the sk_buff field after crc32c but then it was argued
> that maybe another check method may be introduced later and the name
> would be bogus, thus why the "csum_not_inet".
That's sk_buff internals, since Linux can change these
at any time without breaking anything.
virtio defines an ABI so we won't be able to make it
mean something else, need to document it fully.
"Go read linux net core code" is not a good answer
to the natural question "what does this bit in the
interface do".
> >
> > > __u8 flags;
> > > #define VIRTIO_NET_HDR_GSO_NONE 0 /* Not a GSO frame */
> > > #define VIRTIO_NET_HDR_GSO_TCPV4 1 /* GSO frame, IPv4 TCP (TSO) */
> > > --
> > > 2.9.5
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
^ permalink raw reply
* Re: [PATCH] net: stmmac: Avoid VLA usage
From: Alexandre Torgue @ 2018-05-02 14:22 UTC (permalink / raw)
To: Jose Abreu, Kees Cook; +Cc: Giuseppe Cavallaro, LKML, Network Development
In-Reply-To: <4c209618-8da0-ef1d-ff79-5da3f235b9bc@synopsys.com>
On 05/02/2018 04:07 PM, Jose Abreu wrote:
>
>
> On 02-05-2018 13:36, Kees Cook wrote:
>> On Wed, May 2, 2018 at 1:54 AM, Jose Abreu <Jose.Abreu@synopsys.com> wrote:
>>> Hi Kees,
>>>
>>> On 01-05-2018 22:01, Kees Cook wrote:
>>>> In the quest to remove all stack VLAs from the kernel[1], this switches
>>>> the "status" stack buffer to use the existing small (8) upper bound on
>>>> how many queues can be checked for DMA, and adds a sanity-check just to
>>>> make sure it doesn't operate under pathological conditions.
>>>>
>>>> [1] https://urldefense.proofpoint.com/v2/url?u=http-3A__lkml.kernel.org_r_CA-2B55aFzCG-2DzNmZwX4A2FQpadafLfEzK6CC-3DqPXydAacU1RqZWA-40mail.gmail.com&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=WHDsc6kcWAl4i96Vm5hJ_19IJiuxx_p_Rzo2g-uHDKw&m=TBD6a7UY2VbpPmV9LOW_eHAyg8uPq1ZPDhq93VROTVE&s=4fvOST1HhWmZ4lThQe-dHCJYEXNOwey00BCXOWm8tKo&e=
>>>>
>>>> Signed-off-by: Kees Cook <keescook@chromium.org>
>>>>
>>> I rather prefer the variables declaration in reverse-tree order,
>>> but thats just a minor pick.
>> I can explicitly reorder the other variables, if you want?
>
> No need by me, unless Giuseppe or Alexandre prefer that. Thanks!
No need.
>
> Best Regards,
> Jose Miguel Abreu
>
>>
>>> Reviewed-by: Jose Abreu <joabreu@synopsys.com>
>> Thanks!
>>
>>> PS: Is VLA warning switch in gcc already active? Because I didn't
>>> see this warning in my builds.
>> It is not. A bunch of people have been building with KCFLAGS=-Wvla to
>> find the VLAs and sending patches. Once we get rid of them all, we can
>> add the flag to the top-level Makefile.
>>
>> -Kees
>>
>
^ permalink raw reply
* Re: [PATCH V2 net-next 5/6] macvlan/macvtap: Add support for SCTP checksum offload.
From: Vlad Yasevich @ 2018-05-02 14:25 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Vladislav Yasevich, netdev, linux-sctp, virtualization,
virtio-dev, jasowang, nhorman, marcelo.leitner
In-Reply-To: <20180502170424-mutt-send-email-mst@kernel.org>
On 05/02/2018 10:17 AM, Michael S. Tsirkin wrote:
> On Wed, May 02, 2018 at 10:00:14AM -0400, Vlad Yasevich wrote:
>> On 05/02/2018 09:46 AM, Michael S. Tsirkin wrote:
>>> On Wed, May 02, 2018 at 09:27:00AM -0400, Vlad Yasevich wrote:
>>>> On 05/01/2018 11:24 PM, Michael S. Tsirkin wrote:
>>>>> On Tue, May 01, 2018 at 10:07:38PM -0400, Vladislav Yasevich wrote:
>>>>>> Since we now have support for software CRC32c offload, turn it on
>>>>>> for macvlan and macvtap devices so that guests can take advantage
>>>>>> of offload SCTP checksums to the host or host hardware.
>>>>>>
>>>>>> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
>>>>>> ---
>>>>>> drivers/net/macvlan.c | 5 +++--
>>>>>> drivers/net/tap.c | 8 +++++---
>>>>>> 2 files changed, 8 insertions(+), 5 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
>>>>>> index 725f4b4..646b730 100644
>>>>>> --- a/drivers/net/macvlan.c
>>>>>> +++ b/drivers/net/macvlan.c
>>>>>> @@ -834,7 +834,7 @@ static struct lock_class_key macvlan_netdev_addr_lock_key;
>>>>>>
>>>>>> #define ALWAYS_ON_OFFLOADS \
>>>>>> (NETIF_F_SG | NETIF_F_HW_CSUM | NETIF_F_GSO_SOFTWARE | \
>>>>>> - NETIF_F_GSO_ROBUST | NETIF_F_GSO_ENCAP_ALL)
>>>>>> + NETIF_F_GSO_ROBUST | NETIF_F_GSO_ENCAP_ALL | NETIF_F_SCTP_CRC)
>>>>>>
>>>>>> #define ALWAYS_ON_FEATURES (ALWAYS_ON_OFFLOADS | NETIF_F_LLTX)
>>>>>>
>>>>>> @@ -842,7 +842,8 @@ static struct lock_class_key macvlan_netdev_addr_lock_key;
>>>>>> (NETIF_F_SG | NETIF_F_HW_CSUM | NETIF_F_HIGHDMA | NETIF_F_FRAGLIST | \
>>>>>> NETIF_F_GSO | NETIF_F_TSO | NETIF_F_LRO | \
>>>>>> NETIF_F_TSO_ECN | NETIF_F_TSO6 | NETIF_F_GRO | NETIF_F_RXCSUM | \
>>>>>> - NETIF_F_HW_VLAN_CTAG_FILTER | NETIF_F_HW_VLAN_STAG_FILTER)
>>>>>> + NETIF_F_HW_VLAN_CTAG_FILTER | NETIF_F_HW_VLAN_STAG_FILTER | \
>>>>>> + NETIF_F_SCTP_CRC)
>>>>>>
>>>>>> #define MACVLAN_STATE_MASK \
>>>>>> ((1<<__LINK_STATE_NOCARRIER) | (1<<__LINK_STATE_DORMANT))
>>>>>> diff --git a/drivers/net/tap.c b/drivers/net/tap.c
>>>>>> index 9b6cb78..2c8512b 100644
>>>>>> --- a/drivers/net/tap.c
>>>>>> +++ b/drivers/net/tap.c
>>>>>> @@ -369,8 +369,7 @@ rx_handler_result_t tap_handle_frame(struct sk_buff **pskb)
>>>>>> * check, we either support them all or none.
>>>>>> */
>>>>>> if (skb->ip_summed == CHECKSUM_PARTIAL &&
>>>>>> - !(features & NETIF_F_CSUM_MASK) &&
>>>>>> - skb_checksum_help(skb))
>>>>>> + skb_csum_hwoffload_help(skb, features))
>>>>>> goto drop;
>>>>>> if (ptr_ring_produce(&q->ring, skb))
>>>>>> goto drop;
>>>>>> @@ -945,6 +944,9 @@ static int set_offload(struct tap_queue *q, unsigned long arg)
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> + if (arg & TUN_F_SCTP_CSUM)
>>>>>> + feature_mask |= NETIF_F_SCTP_CRC;
>>>>>> +
>>>>>
>>>>> so this still affects TX, shouldn't this affect RX instead?
>>>>
>>>> There is no bit to set on the RX path just like there is no bit to set on the RX patch
>>>> for TUN_F_CSUM.
>>>>
>>>> We only invert TSO offloads, not checksum offloads as the comment below states.
>>>> For checksum, macvtap has to compute the checksum itself in tap_handle_frame() above.
>>>> It uses tx feature bits to see if needs do to the checksum.
>>>>
>>>> If you think we need another flag to macvtap to control RXCSUM, that would need to be
>>>> separate and cover standard TCP checksum as well.
>>>>
>>>> -vlad
>>>
>>> Confused. What is the meaning of TUN_F_SCTP_CSUM? I assume this is
>>> a way for userspace to tell tun device: "I can handle
>>> packets without SCTP checksum, pls send them my way".
>>
>> Yes, just as TUN_F_CSUM means that tun device can handle packets with
>> partial tcp/udp checksum.
>>
>>>
>>> Now what is the implication for macvtap?
>>
>> The implication is exactly the same as for TUN_F_CSUM. If the
>> flag is set on the macvtap device, the TX checksum feature is
>> turned on.
>
> I guess I will have to go back and re-read that code - I do not remember
> what does TUN_F_CSUM does by now. Here is a quick question that might
> help me:
>
> Let's assume userspace does not set TUN_F_SCTP_CSUM and device
> does not calculate the checksums either. I would expect that with
> macvtap this then behaves exactly like now with no overhead.
correct.
>
>>
>>> And why are
>>> you setting NETIF_F_SCTP_CRC which is a flag
>>> that affects packets sent by guest to host?
>>
>> Mainly its because we are using just 1 flag to control checksum
>> offloading and we need to be able control both tx and rx paths.
>
> Well that's not really the case I think. What we have is controls for tx
> offloads for tun. That's TUN_F_CSUM.
> there are no rx offloads - userspace can send what it wants.
>
> These are supposed to translate to rx offloads for macvtap.
> tx offloads shouldn't be affected at all.
Ok. This is how it works for TSO, but looks like there was a disconnect
on the checksum. In both tun and macvtap case, TUN_F_CSUM controls
the tx checksum feature bit.
>
> Maybe that's not the case - as I said need to go back and check.
> Will try to find the time in the next couple of days.
>
>> What you are suggesting that we either invert what TUN_F_CSUM
>> is doing in macvtap case, or have another flag that lets us control
>> TX and RX paths separately.
>>
>> Either case, that would be separate work.
>> -vlad
>
> So assuming TUN_F_CSUM affects tx for macvtap do you
> agree it's a bug? And should we add to it with
> TUN_F_SCTP_CSUM doing the same?
let me think about what it would look like if TUN_F_CSUM
controlled the rx bits...
-vlad
>
>>>
>>>
>>>>>
>>>>>
>>>>>> /* tun/tap driver inverts the usage for TSO offloads, where
>>>>>> * setting the TSO bit means that the userspace wants to
>>>>>> * accept TSO frames and turning it off means that user space
>>>>>> @@ -1077,7 +1079,7 @@ static long tap_ioctl(struct file *file, unsigned int cmd,
>>>>>> case TUNSETOFFLOAD:
>>>>>> /* let the user check for future flags */
>>>>>> if (arg & ~(TUN_F_CSUM | TUN_F_TSO4 | TUN_F_TSO6 |
>>>>>> - TUN_F_TSO_ECN | TUN_F_UFO))
>>>>>> + TUN_F_TSO_ECN | TUN_F_UFO | TUN_F_SCTP_CSUM))
>>>>>> return -EINVAL;
>>>>>>
>>>>>> rtnl_lock();
>>>>>> --
>>>>>> 2.9.5
^ permalink raw reply
* Re: [PATCH v2] net/mlx4_en: fix potential use-after-free with dma_unmap_page
From: David Miller @ 2018-05-02 14:26 UTC (permalink / raw)
To: tariqt; +Cc: srn, yishaih, netdev
In-Reply-To: <5ee8574e-154c-3fa6-8b29-09fae1d08861@mellanox.com>
From: Tariq Toukan <tariqt@mellanox.com>
Date: Wed, 2 May 2018 16:50:28 +0300
> This patch fixes an issue existing in old kernels. It is not relevant
> per latest code.
>
> So I'm not sure about the process. After I review it, do I just submit
> it again for -stable?
If that's the case, yes that is what you do, just submit it for -stable
and add a note to the top of the commit message body that says something
like:
[ Not relevant upstream, therefore no upstream commit. ]
As -stable submissions have to say what their upstream commit ID is
otherwise.
CC: me on the submission, thank you.
Thanks.
^ permalink raw reply
* Re: [PATCH] Revert "vhost: make msg padding explicit"
From: David Miller @ 2018-05-02 14:27 UTC (permalink / raw)
To: mst; +Cc: linux-kernel, jasowang, kvm, virtualization, netdev
In-Reply-To: <1525270740-460646-1-git-send-email-mst@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Wed, 2 May 2018 17:19:05 +0300
> This reverts commit 93c0d549c4c5a7382ad70de6b86610b7aae57406.
>
> Unfortunately the padding will break 32 bit userspace.
> Ouch. Need to add some compat code, revert for now.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Applied, thanks Michael.
^ permalink raw reply
* Re: [PATCH RFC iproute2-next 2/2] rdma: print provider resource attributes
From: Stephen Hemminger @ 2018-05-02 14:32 UTC (permalink / raw)
To: Leon Romanovsky; +Cc: Steve Wise, dsahern, netdev, linux-rdma
In-Reply-To: <20180502133852.GK20375@mtr-leonro.local>
[-- Attachment #1: Type: text/plain, Size: 1938 bytes --]
On Wed, 2 May 2018 16:38:52 +0300
Leon Romanovsky <leon@kernel.org> wrote:
> On Mon, Apr 30, 2018 at 08:25:24AM -0700, Stephen Hemminger wrote:
> > On Mon, 30 Apr 2018 07:36:18 -0700
> > Steve Wise <swise@opengridcomputing.com> wrote:
> >
> > > +#define nla_type(attr) ((attr)->nla_type & NLA_TYPE_MASK)
> > > +
> > > +void newline(struct rd *rd)
> > > +{
> > > + if (rd->json_output)
> > > + jsonw_end_array(rd->jw);
> > > + else
> > > + pr_out("\n");
> > > +}
> > > +
> > > +void newline_indent(struct rd *rd)
> > > +{
> > > + newline(rd);
> > > + if (!rd->json_output)
> > > + pr_out(" ");
> > > +}
> > > +
> > > +static int print_provider_string(struct rd *rd, const char *key_str,
> > > + const char *val_str)
> > > +{
> > > + if (rd->json_output) {
> > > + jsonw_string_field(rd->jw, key_str, val_str);
> > > + return 0;
> > > + } else {
> > > + return pr_out("%s %s ", key_str, val_str);
> > > + }
> > > +}
> > > +
> > > +static int print_provider_s32(struct rd *rd, const char *key_str, int32_t val,
> > > + enum rdma_nldev_print_type print_type)
> > > +{
> > > + if (rd->json_output) {
> > > + jsonw_int_field(rd->jw, key_str, val);
> > > + return 0;
> > > + }
> > > + switch (print_type) {
> > > + case RDMA_NLDEV_PRINT_TYPE_UNSPEC:
> > > + return pr_out("%s %d ", key_str, val);
> > > + case RDMA_NLDEV_PRINT_TYPE_HEX:
> > > + return pr_out("%s 0x%x ", key_str, val);
> > > + default:
> > > + return -EINVAL;
> > > + }
> > > +}
> > > +
> >
> > This code should get converted to json_print library that handles the
> > different output modes; rather than rolling it's own equivalent functionality.
>
> Can it be done after this patch is merged? It will simplify review and
> testing because current code is implemented to be in the same format as
> the rest of the tool.
>
> Thanks
Sure, I was just encouraging future direction.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH V2 net-next 1/6] virtio: Add support for SCTP checksum offloading
From: Marcelo Ricardo Leitner @ 2018-05-02 14:34 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Vladislav Yasevich, netdev, linux-sctp, virtualization,
virtio-dev, jasowang, nhorman, Vladislav Yasevich
In-Reply-To: <20180502171943-mutt-send-email-mst@kernel.org>
On Wed, May 02, 2018 at 05:21:38PM +0300, Michael S. Tsirkin wrote:
> On Wed, May 02, 2018 at 11:14:13AM -0300, Marcelo Ricardo Leitner wrote:
> > On Wed, May 02, 2018 at 06:16:45AM +0300, Michael S. Tsirkin wrote:
> > > On Tue, May 01, 2018 at 10:07:34PM -0400, Vladislav Yasevich wrote:
> > > > To support SCTP checksum offloading, we need to add a new feature
> > > > to virtio_net, so we can negotiate support between the hypervisor
> > > > and the guest.
> > > > The HOST feature bit signifies offloading support for transmit and
> > > > enables device offload features.
> > > > The GUEST feature bit signifies offloading support of recieve and
> > > > is currently only used by the driver in case of xdp.
> > > >
> > > > That patch also adds an addition virtio_net header flag which
> > > > mirrors the skb->csum_not_inet flag. This flags is used to indicate
> > > > that is this an SCTP packet that needs its checksum computed by the
> > > > lower layer. In this case, the lower layer is the host hypervisor or
> > > > possibly HW nic that supporst CRC32c offload.
> > > >
> > > > In the case that GUEST feature bit is flag, it will be possible to
> > > > receive a virtio_net header with this bit set, which will set the
> > > > corresponding skb bit. SCTP protocol will be updated to correctly
> > > > deal with it.
> > > >
> > > > Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
> > > > ---
> > > > drivers/net/virtio_net.c | 14 +++++++++++++-
> > > > include/linux/virtio_net.h | 6 ++++++
> > > > include/uapi/linux/virtio_net.h | 5 +++++
> > > > 3 files changed, 24 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> > > > index 7b187ec..34af280 100644
> > > > --- a/drivers/net/virtio_net.c
> > > > +++ b/drivers/net/virtio_net.c
> > > > @@ -2148,6 +2148,8 @@ static int virtnet_clear_guest_offloads(struct virtnet_info *vi)
> > > >
> > > > if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_CSUM))
> > > > offloads = 1ULL << VIRTIO_NET_F_GUEST_CSUM;
> > > > + if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_SCTP_CSUM))
> > > > + offloads |= 1ULL << VIRTIO_NET_F_GUEST_SCTP_CSUM;
> > > >
> > > > return virtnet_set_guest_offloads(vi, offloads);
> > > > }
> > > > @@ -2160,6 +2162,8 @@ static int virtnet_restore_guest_offloads(struct virtnet_info *vi)
> > > > return 0;
> > > > if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_CSUM))
> > > > offloads |= 1ULL << VIRTIO_NET_F_GUEST_CSUM;
> > > > + if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_GUEST_SCTP_CSUM))
> > > > + offloads |= 1ULL << VIRTIO_NET_F_GUEST_SCTP_CSUM;
> > > >
> > > > return virtnet_set_guest_offloads(vi, offloads);
> > > > }
> > > > @@ -2724,6 +2728,7 @@ static int virtnet_probe(struct virtio_device *vdev)
> > > > /* Do we support "hardware" checksums? */
> > > > if (virtio_has_feature(vdev, VIRTIO_NET_F_CSUM)) {
> > > > /* This opens up the world of extra features. */
> > > > +
> > > > dev->hw_features |= NETIF_F_HW_CSUM | NETIF_F_SG;
> > > > if (csum)
> > > > dev->features |= NETIF_F_HW_CSUM | NETIF_F_SG;
> > > > @@ -2746,9 +2751,15 @@ static int virtnet_probe(struct virtio_device *vdev)
> > > > dev->features |= dev->hw_features & NETIF_F_ALL_TSO;
> > > > /* (!csum && gso) case will be fixed by register_netdev() */
> > > > }
> > > > +
> > > > if (virtio_has_feature(vdev, VIRTIO_NET_F_GUEST_CSUM))
> > > > dev->features |= NETIF_F_RXCSUM;
> > > >
> > > > + if (virtio_has_feature(vdev, VIRTIO_NET_F_HOST_SCTP_CSUM)) {
> > > > + dev->hw_features |= NETIF_F_SCTP_CRC;
> > > > + dev->features |= NETIF_F_SCTP_CRC;
> > > > + }
> > > > +
> > > > dev->vlan_features = dev->features;
> > > >
> > > > /* MTU range: 68 - 65535 */
> > > > @@ -2962,7 +2973,8 @@ static struct virtio_device_id id_table[] = {
> > > > VIRTIO_NET_F_GUEST_ANNOUNCE, VIRTIO_NET_F_MQ, \
> > > > VIRTIO_NET_F_CTRL_MAC_ADDR, \
> > > > VIRTIO_NET_F_MTU, VIRTIO_NET_F_CTRL_GUEST_OFFLOADS, \
> > > > - VIRTIO_NET_F_SPEED_DUPLEX
> > > > + VIRTIO_NET_F_SPEED_DUPLEX, \
> > > > + VIRTIO_NET_F_HOST_SCTP_CSUM, VIRTIO_NET_F_GUEST_SCTP_CSUM
> > > >
> > > > static unsigned int features[] = {
> > > > VIRTNET_FEATURES,
> > > > diff --git a/include/linux/virtio_net.h b/include/linux/virtio_net.h
> > > > index f144216..28fffdc 100644
> > > > --- a/include/linux/virtio_net.h
> > > > +++ b/include/linux/virtio_net.h
> > > > @@ -39,6 +39,9 @@ static inline int virtio_net_hdr_to_skb(struct sk_buff *skb,
> > > >
> > > > if (!skb_partial_csum_set(skb, start, off))
> > > > return -EINVAL;
> > > > +
> > > > + if (hdr->flags & VIRTIO_NET_HDR_F_CSUM_NOT_INET)
> > > > + skb->csum_not_inet = 1;
> > > > }
> > > >
> > > > if (hdr->gso_type != VIRTIO_NET_HDR_GSO_NONE) {
> > > > @@ -91,6 +94,9 @@ static inline int virtio_net_hdr_from_skb(const struct sk_buff *skb,
> > > > skb_checksum_start_offset(skb));
> > > > hdr->csum_offset = __cpu_to_virtio16(little_endian,
> > > > skb->csum_offset);
> > > > +
> > > > + if (skb->csum_not_inet)
> > > > + hdr->flags |= VIRTIO_NET_HDR_F_CSUM_NOT_INET;
> > > > } else if (has_data_valid &&
> > > > skb->ip_summed == CHECKSUM_UNNECESSARY) {
> > > > hdr->flags = VIRTIO_NET_HDR_F_DATA_VALID;
> > > > diff --git a/include/uapi/linux/virtio_net.h b/include/uapi/linux/virtio_net.h
> > > > index 5de6ed3..9dfca1a 100644
> > > > --- a/include/uapi/linux/virtio_net.h
> > > > +++ b/include/uapi/linux/virtio_net.h
> > > > @@ -57,6 +57,10 @@
> > > > * Steering */
> > > > #define VIRTIO_NET_F_CTRL_MAC_ADDR 23 /* Set MAC address */
> > > >
> > > > +#define VIRTIO_NET_F_GUEST_SCTP_CSUM 61 /* Guest handles SCTP pks w/ partial
> > > > + * csum */
> > > > +#define VIRTIO_NET_F_HOST_SCTP_CSUM 62 /* HOST handles SCTP pkts w/ partial
> > > > + * csum */
> > > > #define VIRTIO_NET_F_SPEED_DUPLEX 63 /* Device set linkspeed and duplex */
> > > >
> > > > #ifndef VIRTIO_NET_NO_LEGACY
> > > > @@ -101,6 +105,7 @@ struct virtio_net_config {
> > > > struct virtio_net_hdr_v1 {
> > > > #define VIRTIO_NET_HDR_F_NEEDS_CSUM 1 /* Use csum_start, csum_offset */
> > > > #define VIRTIO_NET_HDR_F_DATA_VALID 2 /* Csum is valid */
> > > > +#define VIRTIO_NET_HDR_F_CSUM_NOT_INET 4 /* Checksum is not inet */
> > >
> > > Both comment and name are not very informative.
> > > How about just saying CRC32c ?
> >
> > csum_not_inet is following the nomenclature used in sk_buff. Initially
> > Davide had named the sk_buff field after crc32c but then it was argued
> > that maybe another check method may be introduced later and the name
> > would be bogus, thus why the "csum_not_inet".
>
> That's sk_buff internals, since Linux can change these
> at any time without breaking anything.
>
> virtio defines an ABI so we won't be able to make it
> mean something else, need to document it fully.
> "Go read linux net core code" is not a good answer
> to the natural question "what does this bit in the
> interface do".
Fair enough, but as I just said that is exactly why it was named
'csum_not_inet' in the first place, so that it wouldn't have to change
if another method needs to be added.
But I guess your main point is that virtio can have a cleaner ABI and
skip this csum_not_inet case (which is only there because sk_buff
doesn't have as many bits as we would want), right?
>
> > >
> > > > __u8 flags;
> > > > #define VIRTIO_NET_HDR_GSO_NONE 0 /* Not a GSO frame */
> > > > #define VIRTIO_NET_HDR_GSO_TCPV4 1 /* GSO frame, IPv4 TCP (TSO) */
> > > > --
> > > > 2.9.5
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH V2 net-next 2/6] sctp: Handle sctp packets with CHECKSUM_PARTIAL
From: Marcelo Ricardo Leitner @ 2018-05-02 14:38 UTC (permalink / raw)
To: Vladislav Yasevich
Cc: netdev, linux-sctp, virtualization, virtio-dev, mst, jasowang,
nhorman, Vladislav Yasevich
In-Reply-To: <20180502020739.19239-3-vyasevic@redhat.com>
On Tue, May 01, 2018 at 10:07:35PM -0400, Vladislav Yasevich wrote:
> With SCTP checksum offload available in virtio, it is now
> possible for virtio to receive a sctp packet with CHECKSUM_PARTIAL
> set (guest-to-guest traffic). SCTP doesn't really have a
> partial checksum like TCP does, because CRC32c can't do partial
> additive checksumming. It's all or nothing. So an SCTP packet
> with CHECKSUM_PARTIAL will have checksum set to 0. Let SCTP
> treat this as a valid checksum if CHECKSUM_PARTIAL is set.
>
> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
> ---
> net/sctp/input.c | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/net/sctp/input.c b/net/sctp/input.c
> index ba8a6e6..055b8ffa 100644
> --- a/net/sctp/input.c
> +++ b/net/sctp/input.c
> @@ -80,8 +80,17 @@ static inline int sctp_rcv_checksum(struct net *net, struct sk_buff *skb)
> {
> struct sctphdr *sh = sctp_hdr(skb);
> __le32 cmp = sh->checksum;
> - __le32 val = sctp_compute_cksum(skb, 0);
> + __le32 val = 0;
>
> + /* In sctp PARTIAL checksum is always 0. This is a case of
> + * a packet received from guest that supports checksum offload.
> + * Assume it's correct as there is really no way to verify,
> + * and we want to avaoid computing it unnecesarily.
nit, typos --^ --^
> + */
> + if (skb->ip_summed == CHECKSUM_PARTIAL)
> + return 0;
> +
> + val = sctp_compute_cksum(skb, 0);
> if (val != cmp) {
> /* CRC failure, dump it. */
> __SCTP_INC_STATS(net, SCTP_MIB_CHECKSUMERRORS);
> --
> 2.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] vhost: make msg padding explicit
From: Kevin Easton @ 2018-05-02 14:40 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: David Miller, linux-kernel, jasowang, kvm, virtualization, netdev
In-Reply-To: <20180502171909-mutt-send-email-mst@kernel.org>
On Wed, May 02, 2018 at 05:19:27PM +0300, Michael S. Tsirkin wrote:
> On Wed, May 02, 2018 at 10:04:46AM -0400, David Miller wrote:
> > From: "Michael S. Tsirkin" <mst@redhat.com>
> > Date: Wed, 2 May 2018 16:36:37 +0300
> >
> > > Ouch. True - and in particular the 32 bit ABI on 64 bit kernels doesn't
> > > work at all. Hmm. It's relatively new and maybe there aren't any 32 bit
> > > users yet. Thoughts?
> >
> > If it's been in a released kernel version, we really aren't at liberty
> > to play "maybe nobody uses this" UAPI changing games.
> >
> > Please send me a revert.
>
> Sent. Looking at compat mess now.
Just naming the padding field isn't sufficient anyway, there also needs to
be code in vhost_new_msg() to initialise it using the name.
- Kevin
^ permalink raw reply
* Re: [PATCH V2 6/8] net: stmmac: add dwmac-4.20a compatible
From: Jose Abreu @ 2018-05-02 14:41 UTC (permalink / raw)
To: Christophe Roullier, mark.rutland, mcoquelin.stm32,
alexandre.torgue, peppe.cavallaro
Cc: devicetree, linux-arm-kernel, netdev, andrew
In-Reply-To: <1525270723-18241-7-git-send-email-christophe.roullier@st.com>
Hi Christophe,
On 02-05-2018 15:18, Christophe Roullier wrote:
> Manage dwmac-4.20a version from synopsys
>
>
Just being curious: Can you tell me which HW features do you have
on your NIC?
Thanks and Best Regards,
Jose Miguel Abreu
^ permalink raw reply
* Re: [PATCH net-next 0/4] net/smc: fixes 2018/04/30
From: Ursula Braun @ 2018-05-02 14:53 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, raspl
In-Reply-To: <20180430.210351.716233311438621264.davem@davemloft.net>
On 05/01/2018 03:03 AM, David Miller wrote:
> From: Ursula Braun <ubraun@linux.ibm.com>
> Date: Mon, 30 Apr 2018 16:51:15 +0200
>
>> From: Ursula Braun <ursula.braun@linux.ibm.com>
>>
>> Dave,
>>
>> here are 4 smc patches for net-next covering different areas:
>> * link health check
>> * diagnostics for IPv6 smc sockets
>> * ioctl
>> * improvement for vlan determination
>
> You say "fixes" in your Subject line but adding ipv6 smc
> socket diag support is a feature not a fix.
Sorry, I just reused my old subject pattern without reflecting it.
These 4 patches are new features for SMC, and thus the title
should have been "net/smc: features 2018/04/30".
I am going to send v2 with such a title.
>
> Actually, generally speaking your patch submissions are
> confusing.
>
> You do submit really pure bug fixes, but for some odd
> reason you target the net-next tree instead of net.
>
> Maybe you have a good reason for doing this and you can
> explain it to me?
>
Currently we just have one patch queue for upstream posting and
do not separate smc bug fixes from smc features. It is easier to
keep this patch queue and send them for net-next. Thus in the past
I have submitted bug fixes regarded as minor for net-next as well.
But in future I will send pure bug fixes always for net.
^ permalink raw reply
* Re: [PATCH V2 net-next 4/6] tun: Add support for SCTP checksum offload
From: Marcelo Ricardo Leitner @ 2018-05-02 14:53 UTC (permalink / raw)
To: Vladislav Yasevich
Cc: netdev, linux-sctp, virtualization, virtio-dev, mst, jasowang,
nhorman, Vladislav Yasevich
In-Reply-To: <20180502020739.19239-5-vyasevic@redhat.com>
On Tue, May 01, 2018 at 10:07:37PM -0400, Vladislav Yasevich wrote:
> Adds a new tun offload flag to allow for SCTP checksum offload.
> The flag has to be set by the user and defaults to "no offload".
I'm confused here:
> +++ b/drivers/net/tun.c
> @@ -216,7 +216,7 @@ struct tun_struct {
> struct net_device *dev;
> netdev_features_t set_features;
> #define TUN_USER_FEATURES (NETIF_F_HW_CSUM|NETIF_F_TSO_ECN|NETIF_F_TSO| \
> - NETIF_F_TSO6)
> + NETIF_F_TSO6|NETIF_F_SCTP_CRC)
Doesn't adding it here mean it defaults to "offload", instead?
later on, it does:
dev->hw_features = NETIF_F_SG | NETIF_F_FRAGLIST |
TUN_USER_FEATURES | NETIF_F_HW_VLAN_CTAG_TX |
NETIF_F_HW_VLAN_STAG_TX;
^ permalink raw reply
* [PATCH net 1/1] net/smc: restrict non-blocking connect finish
From: Ursula Braun @ 2018-05-02 14:53 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, raspl, ubraun
The smc_poll code tries to finish connect() if the socket is in
state SMC_INIT and polling of the internal CLC-socket returns with
EPOLLOUT. This makes sense for a select/poll call following a connect
call, but not without preceding connect().
With this patch smc_poll starts connect logic only, if the CLC-socket
is no longer in its initial state TCP_CLOSE.
In addition, a poll error on the internal CLC-socket is always
propagated to the SMC socket.
With this patch the code path mentioned by syzbot
https://syzkaller.appspot.com/bug?extid=03faa2dc16b8b64be396
is no longer possible.
Signed-off-by: Ursula Braun <ubraun@linux.ibm.com>
Reported-by: syzbot+03faa2dc16b8b64be396@syzkaller.appspotmail.com
---
net/smc/af_smc.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
index 4470501374bf..8b4c059bd13b 100644
--- a/net/smc/af_smc.c
+++ b/net/smc/af_smc.c
@@ -1166,13 +1166,15 @@ static __poll_t smc_poll(struct file *file, struct socket *sock,
/* delegate to CLC child sock */
release_sock(sk);
mask = smc->clcsock->ops->poll(file, smc->clcsock, wait);
- /* if non-blocking connect finished ... */
lock_sock(sk);
- if ((sk->sk_state == SMC_INIT) && (mask & EPOLLOUT)) {
- sk->sk_err = smc->clcsock->sk->sk_err;
- if (sk->sk_err) {
- mask |= EPOLLERR;
- } else {
+ sk->sk_err = smc->clcsock->sk->sk_err;
+ if (sk->sk_err) {
+ mask |= EPOLLERR;
+ } else {
+ /* if non-blocking connect finished ... */
+ if (sk->sk_state == SMC_INIT &&
+ mask & EPOLLOUT &&
+ smc->clcsock->sk->sk_state != TCP_CLOSE) {
rc = smc_connect_rdma(smc);
if (rc < 0)
mask |= EPOLLERR;
--
2.13.5
^ permalink raw reply related
* Re: [PATCH V2 net-next 4/6] tun: Add support for SCTP checksum offload
From: Marcelo Ricardo Leitner @ 2018-05-02 14:56 UTC (permalink / raw)
To: Vladislav Yasevich
Cc: netdev, linux-sctp, virtualization, virtio-dev, mst, jasowang,
nhorman, Vladislav Yasevich
In-Reply-To: <20180502145347.GG5105@localhost.localdomain>
On Wed, May 02, 2018 at 11:53:47AM -0300, Marcelo Ricardo Leitner wrote:
> On Tue, May 01, 2018 at 10:07:37PM -0400, Vladislav Yasevich wrote:
> > Adds a new tun offload flag to allow for SCTP checksum offload.
> > The flag has to be set by the user and defaults to "no offload".
>
> I'm confused here:
>
> > +++ b/drivers/net/tun.c
> > @@ -216,7 +216,7 @@ struct tun_struct {
> > struct net_device *dev;
> > netdev_features_t set_features;
> > #define TUN_USER_FEATURES (NETIF_F_HW_CSUM|NETIF_F_TSO_ECN|NETIF_F_TSO| \
> > - NETIF_F_TSO6)
> > + NETIF_F_TSO6|NETIF_F_SCTP_CRC)
>
> Doesn't adding it here mean it defaults to "offload", instead?
>
> later on, it does:
> dev->hw_features = NETIF_F_SG | NETIF_F_FRAGLIST |
> TUN_USER_FEATURES | NETIF_F_HW_VLAN_CTAG_TX |
> NETIF_F_HW_VLAN_STAG_TX;
Missed to paste the next line too:
dev->features = dev->hw_features | NETIF_F_LLTX;
^ permalink raw reply
* [PATCH net-next v2 0/4] net/smc: small features 2018/04/30
From: Ursula Braun @ 2018-05-02 14:56 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, raspl, ubraun
From: Ursula Braun <ursula.braun@linux.ibm.com>
Dave,
here are 4 smc patches for net-next covering small new features
in different areas:
* link health check
* diagnostics for IPv6 smc sockets
* ioctl
* improvement for vlan determination
v2 changes:
* better title
* patch 2 - remove compile problem for disabled CONFIG_IPV6
Thanks, Ursula
Karsten Graul (2):
net/smc: periodic testlink support
net/smc: ipv6 support for smc_diag.c
Ursula Braun (2):
net/smc: handle ioctls SIOCINQ, SIOCOUTQ, and SIOCOUTQNSD
net/smc: determine vlan_id of stacked net_device
net/smc/af_smc.c | 39 +++++++++++++++++++++++++++++-----
net/smc/smc_core.c | 28 +++++++++++++++++++++---
net/smc/smc_core.h | 4 ++++
net/smc/smc_diag.c | 39 ++++++++++++++++++++++++++--------
net/smc/smc_llc.c | 62 +++++++++++++++++++++++++++++++++++++++++++++++++++++-
net/smc/smc_llc.h | 3 +++
net/smc/smc_wr.c | 1 +
7 files changed, 158 insertions(+), 18 deletions(-)
--
2.13.5
^ permalink raw reply
* [PATCH net-next v2 1/4] net/smc: periodic testlink support
From: Ursula Braun @ 2018-05-02 14:56 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, raspl, ubraun
In-Reply-To: <20180502145647.36147-1-ubraun@linux.ibm.com>
From: Karsten Graul <kgraul@linux.ibm.com>
Add periodic LLC testlink support to ensure the link is still active.
The interval time is initialized using the value of
sysctl_tcp_keepalive_time.
Signed-off-by: Karsten Graul <kgraul@linux.ibm.com>
Signed-off-by: Ursula Braun <ubraun@linux.ibm.com>
---
net/smc/af_smc.c | 6 ++++--
net/smc/smc_core.c | 2 ++
net/smc/smc_core.h | 4 ++++
net/smc/smc_llc.c | 62 +++++++++++++++++++++++++++++++++++++++++++++++++++++-
net/smc/smc_llc.h | 3 +++
net/smc/smc_wr.c | 1 +
6 files changed, 75 insertions(+), 3 deletions(-)
diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
index 20aa4175b9f8..961b8eff9553 100644
--- a/net/smc/af_smc.c
+++ b/net/smc/af_smc.c
@@ -294,6 +294,7 @@ static void smc_copy_sock_settings_to_smc(struct smc_sock *smc)
static int smc_clnt_conf_first_link(struct smc_sock *smc)
{
+ struct net *net = sock_net(smc->clcsock->sk);
struct smc_link_group *lgr = smc->conn.lgr;
struct smc_link *link;
int rest;
@@ -353,7 +354,7 @@ static int smc_clnt_conf_first_link(struct smc_sock *smc)
if (rc < 0)
return SMC_CLC_DECL_TCL;
- link->state = SMC_LNK_ACTIVE;
+ smc_llc_link_active(link, net->ipv4.sysctl_tcp_keepalive_time);
return 0;
}
@@ -715,6 +716,7 @@ void smc_close_non_accepted(struct sock *sk)
static int smc_serv_conf_first_link(struct smc_sock *smc)
{
+ struct net *net = sock_net(smc->clcsock->sk);
struct smc_link_group *lgr = smc->conn.lgr;
struct smc_link *link;
int rest;
@@ -769,7 +771,7 @@ static int smc_serv_conf_first_link(struct smc_sock *smc)
return rc;
}
- link->state = SMC_LNK_ACTIVE;
+ smc_llc_link_active(link, net->ipv4.sysctl_tcp_keepalive_time);
return 0;
}
diff --git a/net/smc/smc_core.c b/net/smc/smc_core.c
index f44f6803f7ff..d9247765aff3 100644
--- a/net/smc/smc_core.c
+++ b/net/smc/smc_core.c
@@ -310,6 +310,7 @@ static void smc_lgr_free_bufs(struct smc_link_group *lgr)
/* remove a link group */
void smc_lgr_free(struct smc_link_group *lgr)
{
+ smc_llc_link_flush(&lgr->lnk[SMC_SINGLE_LINK]);
smc_lgr_free_bufs(lgr);
smc_link_clear(&lgr->lnk[SMC_SINGLE_LINK]);
kfree(lgr);
@@ -332,6 +333,7 @@ void smc_lgr_terminate(struct smc_link_group *lgr)
struct rb_node *node;
smc_lgr_forget(lgr);
+ smc_llc_link_inactive(&lgr->lnk[SMC_SINGLE_LINK]);
write_lock_bh(&lgr->conns_lock);
node = rb_first(&lgr->conns_all);
diff --git a/net/smc/smc_core.h b/net/smc/smc_core.h
index 07e2a393e6d9..97339f03ba79 100644
--- a/net/smc/smc_core.h
+++ b/net/smc/smc_core.h
@@ -79,6 +79,7 @@ struct smc_link {
dma_addr_t wr_rx_dma_addr; /* DMA address of wr_rx_bufs */
u64 wr_rx_id; /* seq # of last recv WR */
u32 wr_rx_cnt; /* number of WR recv buffers */
+ unsigned long wr_rx_tstamp; /* jiffies when last buf rx */
struct ib_reg_wr wr_reg; /* WR register memory region */
wait_queue_head_t wr_reg_wait; /* wait for wr_reg result */
@@ -101,6 +102,9 @@ struct smc_link {
int llc_confirm_resp_rc; /* rc from conf_resp msg */
struct completion llc_add; /* wait for rx of add link */
struct completion llc_add_resp; /* wait for rx of add link rsp*/
+ struct delayed_work llc_testlink_wrk; /* testlink worker */
+ struct completion llc_testlink_resp; /* wait for rx of testlink */
+ int llc_testlink_time; /* testlink interval */
};
/* For now we just allow one parallel link per link group. The SMC protocol
diff --git a/net/smc/smc_llc.c b/net/smc/smc_llc.c
index ea4b21981b4b..33b4d856f4c6 100644
--- a/net/smc/smc_llc.c
+++ b/net/smc/smc_llc.c
@@ -397,7 +397,8 @@ static void smc_llc_rx_test_link(struct smc_link *link,
struct smc_llc_msg_test_link *llc)
{
if (llc->hd.flags & SMC_LLC_FLAG_RESP) {
- /* unused as long as we don't send this type of msg */
+ if (link->state == SMC_LNK_ACTIVE)
+ complete(&link->llc_testlink_resp);
} else {
smc_llc_send_test_link(link, llc->user_data, SMC_LLC_RESP);
}
@@ -502,6 +503,65 @@ static void smc_llc_rx_handler(struct ib_wc *wc, void *buf)
}
}
+/***************************** worker ****************************************/
+
+static void smc_llc_testlink_work(struct work_struct *work)
+{
+ struct smc_link *link = container_of(to_delayed_work(work),
+ struct smc_link, llc_testlink_wrk);
+ unsigned long next_interval;
+ struct smc_link_group *lgr;
+ unsigned long expire_time;
+ u8 user_data[16] = { 0 };
+ int rc;
+
+ lgr = container_of(link, struct smc_link_group, lnk[SMC_SINGLE_LINK]);
+ if (link->state != SMC_LNK_ACTIVE)
+ return; /* don't reschedule worker */
+ expire_time = link->wr_rx_tstamp + link->llc_testlink_time;
+ if (time_is_after_jiffies(expire_time)) {
+ next_interval = expire_time - jiffies;
+ goto out;
+ }
+ reinit_completion(&link->llc_testlink_resp);
+ smc_llc_send_test_link(link, user_data, SMC_LLC_REQ);
+ /* receive TEST LINK response over RoCE fabric */
+ rc = wait_for_completion_interruptible_timeout(&link->llc_testlink_resp,
+ SMC_LLC_WAIT_TIME);
+ if (rc <= 0) {
+ smc_lgr_terminate(lgr);
+ return;
+ }
+ next_interval = link->llc_testlink_time;
+out:
+ schedule_delayed_work(&link->llc_testlink_wrk, next_interval);
+}
+
+void smc_llc_link_active(struct smc_link *link, int testlink_time)
+{
+ init_completion(&link->llc_testlink_resp);
+ INIT_DELAYED_WORK(&link->llc_testlink_wrk, smc_llc_testlink_work);
+ link->state = SMC_LNK_ACTIVE;
+ if (testlink_time) {
+ link->llc_testlink_time = testlink_time * HZ;
+ schedule_delayed_work(&link->llc_testlink_wrk,
+ link->llc_testlink_time);
+ }
+}
+
+/* called in tasklet context */
+void smc_llc_link_inactive(struct smc_link *link)
+{
+ link->state = SMC_LNK_INACTIVE;
+ cancel_delayed_work(&link->llc_testlink_wrk);
+}
+
+/* called in worker context */
+void smc_llc_link_flush(struct smc_link *link)
+{
+ cancel_delayed_work_sync(&link->llc_testlink_wrk);
+}
+
/***************************** init, exit, misc ******************************/
static struct smc_wr_rx_handler smc_llc_rx_handlers[] = {
diff --git a/net/smc/smc_llc.h b/net/smc/smc_llc.h
index e4a7d5e234d5..d6e42116485e 100644
--- a/net/smc/smc_llc.h
+++ b/net/smc/smc_llc.h
@@ -44,6 +44,9 @@ int smc_llc_send_delete_link(struct smc_link *link,
enum smc_llc_reqresp reqresp);
int smc_llc_send_test_link(struct smc_link *lnk, u8 user_data[16],
enum smc_llc_reqresp reqresp);
+void smc_llc_link_active(struct smc_link *link, int testlink_time);
+void smc_llc_link_inactive(struct smc_link *link);
+void smc_llc_link_flush(struct smc_link *link);
int smc_llc_init(void) __init;
#endif /* SMC_LLC_H */
diff --git a/net/smc/smc_wr.c b/net/smc/smc_wr.c
index 1b8af23e6e2b..cc7c1bb60fe8 100644
--- a/net/smc/smc_wr.c
+++ b/net/smc/smc_wr.c
@@ -376,6 +376,7 @@ static inline void smc_wr_rx_process_cqes(struct ib_wc wc[], int num)
for (i = 0; i < num; i++) {
link = wc[i].qp->qp_context;
if (wc[i].status == IB_WC_SUCCESS) {
+ link->wr_rx_tstamp = jiffies;
smc_wr_rx_demultiplex(&wc[i]);
smc_wr_rx_post(link); /* refill WR RX */
} else {
--
2.13.5
^ permalink raw reply related
* [PATCH net-next v2 2/4] net/smc: ipv6 support for smc_diag.c
From: Ursula Braun @ 2018-05-02 14:56 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, raspl, ubraun
In-Reply-To: <20180502145647.36147-1-ubraun@linux.ibm.com>
From: Karsten Graul <kgraul@linux.ibm.com>
Update smc_diag.c to support ipv6 addresses on the diagnosis interface.
Signed-off-by: Karsten Graul <kgraul@linux.ibm.com>
Signed-off-by: Ursula Braun <ubraun@linux.ibm.com>
---
net/smc/smc_diag.c | 39 ++++++++++++++++++++++++++++++---------
1 file changed, 30 insertions(+), 9 deletions(-)
diff --git a/net/smc/smc_diag.c b/net/smc/smc_diag.c
index 427b91c1c964..05dd7e6d314d 100644
--- a/net/smc/smc_diag.c
+++ b/net/smc/smc_diag.c
@@ -38,17 +38,27 @@ static void smc_diag_msg_common_fill(struct smc_diag_msg *r, struct sock *sk)
{
struct smc_sock *smc = smc_sk(sk);
- r->diag_family = sk->sk_family;
if (!smc->clcsock)
return;
r->id.idiag_sport = htons(smc->clcsock->sk->sk_num);
r->id.idiag_dport = smc->clcsock->sk->sk_dport;
r->id.idiag_if = smc->clcsock->sk->sk_bound_dev_if;
sock_diag_save_cookie(sk, r->id.idiag_cookie);
- memset(&r->id.idiag_src, 0, sizeof(r->id.idiag_src));
- memset(&r->id.idiag_dst, 0, sizeof(r->id.idiag_dst));
- r->id.idiag_src[0] = smc->clcsock->sk->sk_rcv_saddr;
- r->id.idiag_dst[0] = smc->clcsock->sk->sk_daddr;
+ if (sk->sk_protocol == SMCPROTO_SMC) {
+ r->diag_family = PF_INET;
+ memset(&r->id.idiag_src, 0, sizeof(r->id.idiag_src));
+ memset(&r->id.idiag_dst, 0, sizeof(r->id.idiag_dst));
+ r->id.idiag_src[0] = smc->clcsock->sk->sk_rcv_saddr;
+ r->id.idiag_dst[0] = smc->clcsock->sk->sk_daddr;
+#if IS_ENABLED(CONFIG_IPV6)
+ } else if (sk->sk_protocol == SMCPROTO_SMC6) {
+ r->diag_family = PF_INET6;
+ memcpy(&r->id.idiag_src, &smc->clcsock->sk->sk_v6_rcv_saddr,
+ sizeof(smc->clcsock->sk->sk_v6_rcv_saddr));
+ memcpy(&r->id.idiag_dst, &smc->clcsock->sk->sk_v6_daddr,
+ sizeof(smc->clcsock->sk->sk_v6_daddr));
+#endif
+ }
}
static int smc_diag_msg_attrs_fill(struct sock *sk, struct sk_buff *skb,
@@ -153,7 +163,8 @@ static int __smc_diag_dump(struct sock *sk, struct sk_buff *skb,
return -EMSGSIZE;
}
-static int smc_diag_dump(struct sk_buff *skb, struct netlink_callback *cb)
+static int smc_diag_dump_proto(struct proto *prot, struct sk_buff *skb,
+ struct netlink_callback *cb)
{
struct net *net = sock_net(skb->sk);
struct nlattr *bc = NULL;
@@ -161,8 +172,8 @@ static int smc_diag_dump(struct sk_buff *skb, struct netlink_callback *cb)
struct sock *sk;
int rc = 0;
- read_lock(&smc_proto.h.smc_hash->lock);
- head = &smc_proto.h.smc_hash->ht;
+ read_lock(&prot->h.smc_hash->lock);
+ head = &prot->h.smc_hash->ht;
if (hlist_empty(head))
goto out;
@@ -175,7 +186,17 @@ static int smc_diag_dump(struct sk_buff *skb, struct netlink_callback *cb)
}
out:
- read_unlock(&smc_proto.h.smc_hash->lock);
+ read_unlock(&prot->h.smc_hash->lock);
+ return rc;
+}
+
+static int smc_diag_dump(struct sk_buff *skb, struct netlink_callback *cb)
+{
+ int rc = 0;
+
+ rc = smc_diag_dump_proto(&smc_proto, skb, cb);
+ if (!rc)
+ rc = smc_diag_dump_proto(&smc_proto6, skb, cb);
return rc;
}
--
2.13.5
^ permalink raw reply related
* [PATCH net-next v2 4/4] net/smc: determine vlan_id of stacked net_device
From: Ursula Braun @ 2018-05-02 14:56 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, raspl, ubraun
In-Reply-To: <20180502145647.36147-1-ubraun@linux.ibm.com>
An SMC link group is bound to a specific vlan_id. Its link uses
the RoCE-GIDs established for the specific vlan_id. This patch makes
sure the appropriate vlan_id is determined for stacked scenarios like
for instance a master bonding device with vlan devices enslaved.
Signed-off-by: Ursula Braun <ubraun@linux.ibm.com>
---
net/smc/smc_core.c | 26 +++++++++++++++++++++++---
1 file changed, 23 insertions(+), 3 deletions(-)
diff --git a/net/smc/smc_core.c b/net/smc/smc_core.c
index d9247765aff3..1f3ea62fac5c 100644
--- a/net/smc/smc_core.c
+++ b/net/smc/smc_core.c
@@ -360,7 +360,8 @@ void smc_lgr_terminate(struct smc_link_group *lgr)
static int smc_vlan_by_tcpsk(struct socket *clcsock, unsigned short *vlan_id)
{
struct dst_entry *dst = sk_dst_get(clcsock->sk);
- int rc = 0;
+ struct net_device *ndev;
+ int i, nest_lvl, rc = 0;
*vlan_id = 0;
if (!dst) {
@@ -372,8 +373,27 @@ static int smc_vlan_by_tcpsk(struct socket *clcsock, unsigned short *vlan_id)
goto out_rel;
}
- if (is_vlan_dev(dst->dev))
- *vlan_id = vlan_dev_vlan_id(dst->dev);
+ ndev = dst->dev;
+ if (is_vlan_dev(ndev)) {
+ *vlan_id = vlan_dev_vlan_id(ndev);
+ goto out_rel;
+ }
+
+ rtnl_lock();
+ nest_lvl = dev_get_nest_level(ndev);
+ for (i = 0; i < nest_lvl; i++) {
+ struct list_head *lower = &ndev->adj_list.lower;
+
+ if (list_empty(lower))
+ break;
+ lower = lower->next;
+ ndev = (struct net_device *)netdev_lower_get_next(ndev, &lower);
+ if (is_vlan_dev(ndev)) {
+ *vlan_id = vlan_dev_vlan_id(ndev);
+ break;
+ }
+ }
+ rtnl_unlock();
out_rel:
dst_release(dst);
--
2.13.5
^ permalink raw reply related
* [PATCH net-next v2 3/4] net/smc: handle ioctls SIOCINQ, SIOCOUTQ, and SIOCOUTQNSD
From: Ursula Braun @ 2018-05-02 14:56 UTC (permalink / raw)
To: davem; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, raspl, ubraun
In-Reply-To: <20180502145647.36147-1-ubraun@linux.ibm.com>
SIOCINQ returns the amount of unread data in the RMB.
SIOCOUTQ returns the amount of unsent or unacked sent data in the send
buffer.
SIOCOUTQNSD returns the amount of data prepared for sending, but
not yet sent.
Signed-off-by: Ursula Braun <ubraun@linux.ibm.com>
---
net/smc/af_smc.c | 33 ++++++++++++++++++++++++++++++---
1 file changed, 30 insertions(+), 3 deletions(-)
diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c
index 961b8eff9553..823ea3371575 100644
--- a/net/smc/af_smc.c
+++ b/net/smc/af_smc.c
@@ -29,6 +29,7 @@
#include <net/sock.h>
#include <net/tcp.h>
#include <net/smc.h>
+#include <asm/ioctls.h>
#include "smc.h"
#include "smc_clc.h"
@@ -1389,12 +1390,38 @@ static int smc_ioctl(struct socket *sock, unsigned int cmd,
unsigned long arg)
{
struct smc_sock *smc;
+ int answ;
smc = smc_sk(sock->sk);
- if (smc->use_fallback)
+ if (smc->use_fallback) {
+ if (!smc->clcsock)
+ return -EBADF;
return smc->clcsock->ops->ioctl(smc->clcsock, cmd, arg);
- else
- return sock_no_ioctl(sock, cmd, arg);
+ }
+ switch (cmd) {
+ case SIOCINQ: /* same as FIONREAD */
+ if (smc->sk.sk_state == SMC_LISTEN)
+ return -EINVAL;
+ answ = atomic_read(&smc->conn.bytes_to_rcv);
+ break;
+ case SIOCOUTQ:
+ /* output queue size (not send + not acked) */
+ if (smc->sk.sk_state == SMC_LISTEN)
+ return -EINVAL;
+ answ = smc->conn.sndbuf_size -
+ atomic_read(&smc->conn.sndbuf_space);
+ break;
+ case SIOCOUTQNSD:
+ /* output queue size (not send only) */
+ if (smc->sk.sk_state == SMC_LISTEN)
+ return -EINVAL;
+ answ = smc_tx_prepared_sends(&smc->conn);
+ break;
+ default:
+ return -ENOIOCTLCMD;
+ }
+
+ return put_user(answ, (int __user *)arg);
}
static ssize_t smc_sendpage(struct socket *sock, struct page *page,
--
2.13.5
^ permalink raw reply related
* Re: [PATCH net-next] udp: Complement partial checksum for GSO packet
From: David Miller @ 2018-05-02 15:00 UTC (permalink / raw)
To: willemdebruijn.kernel; +Cc: stranche, willemb, netdev, subashab
In-Reply-To: <CAF=yD-K+15L9Ui227y04fhrQjCMa5WGyT+rydvM17BF94E8yLw@mail.gmail.com>
From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
Date: Wed, 2 May 2018 11:25:43 +0200
> On Tue, May 1, 2018 at 12:06 PM, Willem de Bruijn
> <willemdebruijn.kernel@gmail.com> wrote:
>> On Tue, May 1, 2018 at 2:01 AM, Sean Tranchetti <stranche@codeaurora.org> wrote:
>>> Using the udp_v4_check() function to calculate the pseudo header
>>> for the newly segmented UDP packets results in assigning the complement
>>> of the value to the UDP header checksum field.
>>>
>>> Always undo the complement the partial checksum value in order to
>>> match the case where GSO is not used on the UDP transmit path.
>>>
>>> Fixes: ee80d1ebe5ba ("udp: add udp gso")
>>> Signed-off-by: Sean Tranchetti <stranche@codeaurora.org>
>>> Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
>
> Acked-by: Willem de Bruijn <willemb@google.com>
>
> Thanks Sean.
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH net-next v2 00/15] ARM: sun8i: r40: Add Ethernet support
From: David Miller @ 2018-05-02 15:04 UTC (permalink / raw)
To: wens
Cc: maxime.ripard, mturquette, sboyd, peppe.cavallaro, robh+dt,
mark.rutland, broonie, linux-arm-kernel, linux-clk, devicetree,
netdev, clabbe.montjoie, icenowy
In-Reply-To: <20180501161227.2110-1-wens@csie.org>
From: Chen-Yu Tsai <wens@csie.org>
Date: Wed, 2 May 2018 00:12:12 +0800
> This is v2 of my R40 Ethernet support series.
There are a lot of non-networking changes in here, in particular DTS
changes and modifications to clock drivers.
Are all parties involved OK with the entire series going into net-next?
Thanks.
^ permalink raw reply
* Re: [PATCH net-next v2 00/15] ARM: sun8i: r40: Add Ethernet support
From: David Miller @ 2018-05-02 15:06 UTC (permalink / raw)
To: wens
Cc: maxime.ripard, mturquette, sboyd, peppe.cavallaro, robh+dt,
mark.rutland, broonie, linux-arm-kernel, linux-clk, devicetree,
netdev, clabbe.montjoie, icenowy
In-Reply-To: <CAGb2v67HFb6eLBS4_9s_wJ5uWFeQdUtwn_NMJnm59UUDFBDJUA@mail.gmail.com>
From: Chen-Yu Tsai <wens@csie.org>
Date: Wed, 2 May 2018 00:33:45 +0800
> I should've mentioned that patches 3 ~ 10, and only these, should go
> through net-next. sunxi will handle the remaining clk, device tree, and
> soc driver patches.
Ok, I just noticed this.
Why don't you just post those patches separately as a series on their
own then, in order to avoid confusion?
Then you can adjust the patch series header posting to explain the
non-net-next changes, where they got merged, and what they provide
in order to faciliate the net-next changes.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] liquidio VF: indicate that disabling rx vlan offload is not allowed
From: David Miller @ 2018-05-02 15:07 UTC (permalink / raw)
To: felix.manlunas
Cc: netdev, raghu.vatsavayi, derek.chickles, satananda.burla,
prasad.kanneganti
In-Reply-To: <20180501173210.GA5083@felix-thinkpad.cavium.com>
From: Felix Manlunas <felix.manlunas@cavium.com>
Date: Tue, 1 May 2018 10:32:10 -0700
> From: Raghu Vatsavayi <raghu.vatsavayi@cavium.com>
>
> NIC firmware does not support disabling rx vlan offload, but the VF driver
> incorrectly indicates that it is supported. The PF driver already does the
> correct indication by clearing the NETIF_F_HW_VLAN_CTAG_RX bit in its
> netdev->hw_features. So just do the same thing in the VF.
>
> Signed-off-by: Raghu Vatsavayi <raghu.vatsavayi@cavium.com>
> Acked-by: Prasad Kanneganti <prasad.kanneganti@cavium.com>
> Signed-off-by: Felix Manlunas <felix.manlunas@cavium.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] net: ethernet: ti: cpsw: fix packet leaking in dual_mac mode
From: David Miller @ 2018-05-02 15:08 UTC (permalink / raw)
To: grygorii.strashko; +Cc: netdev, nsekhar, linux-kernel, linux-omap
In-Reply-To: <20180501174122.11323-1-grygorii.strashko@ti.com>
From: Grygorii Strashko <grygorii.strashko@ti.com>
Date: Tue, 1 May 2018 12:41:22 -0500
> In dual_mac mode packets arrived on one port should not be forwarded by
> switch hw to another port. Only Linux Host can forward packets between
> ports. The below test case (reported in [1]) shows that packet arrived on
> one port can be leaked to anoter (reproducible with dual port evms):
> - connect port 1 (eth0) to linux Host 0 and run tcpdump or Wireshark
> - connect port 2 (eth1) to linux Host 1 with vlan 1 configured
> - ping <IPx> from Host 1 through vlan 1 interface.
> ARP packets will be seen on Host 0.
>
> Issue happens because dual_mac mode is implemnted using two vlans: 1 (Port
> 1+Port 0) and 2 (Port 2+Port 0), so there are vlan records created for for
> each vlan. By default, the ALE will find valid vlan record in its table
> when vlan 1 tagged packet arrived on Port 2 and so forwards packet to all
> ports which are vlan 1 members (like Port.
>
> To avoid such behaviorr the ALE VLAN ID Ingress Check need to be enabled
> for each external CPSW port (ALE_PORTCTLn.VID_INGRESS_CHECK) so ALE will
> drop ingress packets if Rx port is not VLAN member.
>
> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Applied and queued up for -stable, thank you.
^ permalink raw reply
* [PATCH net-next v7 0/7] sched: Add Common Applications Kept Enhanced (cake) qdisc
From: Toke Høiland-Jørgensen @ 2018-05-02 15:10 UTC (permalink / raw)
To: netdev; +Cc: cake
This patch series adds the CAKE qdisc, and has been split up to ease
review.
I have attempted to split out each configurable feature into its own patch.
The first commit adds the base shaper and packet scheduler, while
subsequent commits add the optional features. The full userspace API and
most data structures are included in this commit, but options not
understood in the base version will be ignored.
The result of applying the entire series is identical to the out of tree
version that have seen extensive testing in previous deployments, most
notably as an out of tree patch to OpenWrt. However, note that I have only
compile tested the individual patches; so the whole series should be
considered as a unit.
---
Changelog
v7:
- Split up patch into a series to ease review.
- Constify the ACK filter.
v6:
- Fix 6in4 encapsulation checks in ACK filter code
- Checkpatch fixes
v5:
- Refactor ACK filter code and hopefully fix the safety issues
properly this time.
v4:
- Only split GSO packets if shaping at speeds <= 1Gbps
- Fix overhead calculation code to also work for GSO packets
- Don't re-implement kvzalloc()
- Remove local header include from out-of-tree build (fixes kbuild-bot
complaint).
- Several fixes to the ACK filter:
- Check pskb_may_pull() before deref of transport headers.
- Don't run ACK filter logic on split GSO packets
- Fix TCP sequence number compare to deal with wraparounds
v3:
- Use IS_REACHABLE() macro to fix compilation when sch_cake is
built-in and conntrack is a module.
- Switch the stats output to use nested netlink attributes instead
of a versioned struct.
- Remove GPL boilerplate.
- Fix array initialisation style.
v2:
- Fix kbuild test bot complaint
- Clean up the netlink ABI
- Fix checkpatch complaints
- A few tweaks to the behaviour of cake based on testing carried out
while writing the paper.
Toke Høiland-Jørgensen (7):
sched: Add Common Applications Kept Enhanced (cake) qdisc
sch_cake: Add ingress mode
sch_cake: Add optional ACK filter
sch_cake: Add NAT awareness to packet classifier
sch_cake: Add DiffServ handling
sch_cake: Add overhead compensation support to the rate shaper
sch_cake: Conditionally split GSO segments
include/uapi/linux/pkt_sched.h | 105 ++
net/sched/Kconfig | 11
net/sched/Makefile | 1
net/sched/sch_cake.c | 2697 ++++++++++++++++++++++++++++++++++++++++
4 files changed, 2814 insertions(+)
create mode 100644 net/sched/sch_cake.c
^ 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