* Commit 1fe8e0... (include more headers in if_tunnel.h) breaks my user-space build.
From: Ben Greear @ 2017-01-13 19:12 UTC (permalink / raw)
To: netdev, mikko.rapeli
I am including netinet/ip.h, and also linux/if_tunnel.h, and the linux/ip.h conflicts with
netinet/ip.h.
Maybe my build environment is screwed up, but maybe also it would be better to
just let the user include appropriate headers before including if_tunnel.h
and revert this patch?
include/uapi/linux/if_tunnel.h: include linux/if.h, linux/ip.h and linux/in6.h
Fixes userspace compilation errors like:
error: field ‘iph’ has incomplete type
error: field ‘prefix’ has incomplete type
Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
Signed-off-by: David S. Miller <davem@davemloft.net>
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: Commit 1fe8e0... (include more headers in if_tunnel.h) breaks my user-space build.
From: Ben Greear @ 2017-01-13 19:21 UTC (permalink / raw)
To: netdev, mikko.rapeli
In-Reply-To: <f1cede01-3fa4-130a-fa2d-7cbdfe3648b3@candelatech.com>
On 01/13/2017 11:12 AM, Ben Greear wrote:
> I am including netinet/ip.h, and also linux/if_tunnel.h, and the linux/ip.h conflicts with
> netinet/ip.h.
>
> Maybe my build environment is screwed up, but maybe also it would be better to
> just let the user include appropriate headers before including if_tunnel.h
> and revert this patch?
>
>
> include/uapi/linux/if_tunnel.h: include linux/if.h, linux/ip.h and linux/in6.h
>
> Fixes userspace compilation errors like:
>
> error: field ‘iph’ has incomplete type
> error: field ‘prefix’ has incomplete type
>
> Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
> Thanks,
> Ben
>
I forgot the full commit ID, my abbreviation was not sufficient to be unique it seems:
1fe8e0f074c77aa41aaa579345a9e675acbebfa9
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: Commit 1fe8e0... (include more headers in if_tunnel.h) breaks my user-space build.
From: Stephen Hemminger @ 2017-01-13 19:41 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev, mikko.rapeli
In-Reply-To: <f1cede01-3fa4-130a-fa2d-7cbdfe3648b3@candelatech.com>
On Fri, 13 Jan 2017 11:12:32 -0800
Ben Greear <greearb@candelatech.com> wrote:
> I am including netinet/ip.h, and also linux/if_tunnel.h, and the linux/ip.h conflicts with
> netinet/ip.h.
>
> Maybe my build environment is screwed up, but maybe also it would be better to
> just let the user include appropriate headers before including if_tunnel.h
> and revert this patch?
>
>
> include/uapi/linux/if_tunnel.h: include linux/if.h, linux/ip.h and linux/in6.h
>
> Fixes userspace compilation errors like:
>
> error: field ‘iph’ has incomplete type
> error: field ‘prefix’ has incomplete type
>
> Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
> Thanks,
> Ben
>
What I ended up doing for iproute2 was including all headers used by the source
based on sanitized kernel headers. Basically
$ git grep '^#include <linux/' | \
awk -F: '{print $2}' | \
sed -e 's/^#include <//' -e 's/>.*$//' | \
sort -u >linux.headers
$ for f in $(cat linux.headers)
do cp ~/kernel/net-next/usr/include/$f include/$f
done
You can't take only some of the headers, once you decide to diverge from glibc provided
headers, you got to take them all.
^ permalink raw reply
* Re: Commit 1fe8e0... (include more headers in if_tunnel.h) breaks my user-space build.
From: Ben Greear @ 2017-01-13 19:50 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, mikko.rapeli
In-Reply-To: <20170113114158.6e5c3461@xeon-e3>
On 01/13/2017 11:41 AM, Stephen Hemminger wrote:
> On Fri, 13 Jan 2017 11:12:32 -0800
> Ben Greear <greearb@candelatech.com> wrote:
>
>> I am including netinet/ip.h, and also linux/if_tunnel.h, and the linux/ip.h conflicts with
>> netinet/ip.h.
>>
>> Maybe my build environment is screwed up, but maybe also it would be better to
>> just let the user include appropriate headers before including if_tunnel.h
>> and revert this patch?
>>
>>
>> include/uapi/linux/if_tunnel.h: include linux/if.h, linux/ip.h and linux/in6.h
>>
>> Fixes userspace compilation errors like:
>>
>> error: field ‘iph’ has incomplete type
>> error: field ‘prefix’ has incomplete type
>>
>> Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
>> Signed-off-by: David S. Miller <davem@davemloft.net>
>>
>> Thanks,
>> Ben
>>
>
> What I ended up doing for iproute2 was including all headers used by the source
> based on sanitized kernel headers. Basically
> $ git grep '^#include <linux/' | \
> awk -F: '{print $2}' | \
> sed -e 's/^#include <//' -e 's/>.*$//' | \
> sort -u >linux.headers
> $ for f in $(cat linux.headers)
> do cp ~/kernel/net-next/usr/include/$f include/$f
> done
>
> You can't take only some of the headers, once you decide to diverge from glibc provided
> headers, you got to take them all.
>
I do grab a copy of the linux kernel headers and compile against that, but netinet/ip.h is
coming from the OS. Do you mean I should not include netinet/ip.h and instead use linux/ip.h?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [net PATCH 5/5] virtio_net: XDP support for adjust_head
From: John Fastabend @ 2017-01-13 19:53 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: jasowang, john.r.fastabend, netdev, alexei.starovoitov, daniel
In-Reply-To: <20170113191451-mutt-send-email-mst@kernel.org>
On 17-01-13 09:23 AM, Michael S. Tsirkin wrote:
> On Thu, Jan 12, 2017 at 01:45:19PM -0800, John Fastabend wrote:
>> Add support for XDP adjust head by allocating a 256B header region
>> that XDP programs can grow into. This is only enabled when a XDP
>> program is loaded.
>>
>> In order to ensure that we do not have to unwind queue headroom push
>> queue setup below bpf_prog_add. It reads better to do a prog ref
>> unwind vs another queue setup call.
>>
>> At the moment this code must do a full reset to ensure old buffers
>> without headroom on program add or with headroom on program removal
>> are not used incorrectly in the datapath. Ideally we would only
>> have to disable/enable the RX queues being updated but there is no
>> API to do this at the moment in virtio so use the big hammer. In
>> practice it is likely not that big of a problem as this will only
>> happen when XDP is enabled/disabled changing programs does not
>> require the reset. There is some risk that the driver may either
>> have an allocation failure or for some reason fail to correctly
>> negotiate with the underlying backend in this case the driver will
>> be left uninitialized. I have not seen this ever happen on my test
>> systems and for what its worth this same failure case can occur
>> from probe and other contexts in virtio framework.
>>
>> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
>> ---
[...]
>>
>> +#define VIRTIO_XDP_HEADROOM 256
>> +
>> +static int init_vqs(struct virtnet_info *vi);
>> +static void remove_vq_common(struct virtnet_info *vi, bool lock);
>> +
>> +/* Reset virtio device with RTNL held this is very similar to the
>> + * freeze()/restore() logic except we need to ensure locking. It is
>> + * possible that this routine may fail and leave the driver in a
>> + * failed state. However assuming the driver negotiated correctly
>> + * at probe time we _should_ be able to (re)negotiate driver again.
>> + */
>> +static int virtnet_xdp_reset(struct virtnet_info *vi)
>> +{
>> + struct virtio_device *vdev = vi->vdev;
>> + unsigned int status;
>> + int i, ret;
>> +
>> + /* Disable and unwind rings */
>> + virtio_config_disable(vdev);
>> + vdev->failed = vdev->config->get_status(vdev) & VIRTIO_CONFIG_S_FAILED;
>> +
>> + netif_device_detach(vi->dev);
>
> After this point, netif_device_present
> will return false, and then we have a bunch of code
> that does
> if (!netif_device_present(dev))
> return -ENODEV;
>
>
> so we need to audit this code to make sure it's
> all called under rtnl, correct?
>
Correct. In the XDP case it is.
> We don't want it to fail because of timing.
>
> Maybe add an assert there.
>
I can add an assert here to ensure it doesn't ever get
refactored out or something.
>
>> + cancel_delayed_work_sync(&vi->refill);
>> + if (netif_running(vi->dev)) {
>> + for (i = 0; i < vi->max_queue_pairs; i++)
>> + napi_disable(&vi->rq[i].napi);
>> + }
>> +
>> + remove_vq_common(vi, false);
>> +
>> + /* Do a reset per virtio spec recommendation */
>> + vdev->config->reset(vdev);
>> +
>> + /* Acknowledge that we've seen the device. */
>> + status = vdev->config->get_status(vdev);
>> + vdev->config->set_status(vdev, status | VIRTIO_CONFIG_S_ACKNOWLEDGE);
>> +
>> + /* Notify driver is up and finalize features per specification. The
>> + * error code from finalize features is checked here but should not
>> + * fail because we assume features were previously synced successfully.
>> + */
>> + status = vdev->config->get_status(vdev);
>> + vdev->config->set_status(vdev, status | VIRTIO_CONFIG_S_DRIVER);
>> + ret = virtio_finalize_features(vdev);
>
> I'd rather we put all this in virtio core, maybe call it virtio_reset or
> something.
At first I started to do this but decided it was easier to open code it I
was on the fence though so if we think it would be cleaner then I will
do it.
The trick is needs to be broken down into two pieces, something like the
following,
virtio_reset() {
do_generic_down_part -> pci pieces
vdev->config->down() -> do down part of device specifics
do_generic_up_part
vdev->config->up() -> do up part of device specifics
do_finalize_part
}
Alternatively we could reuse the freeze/restore device callbacks but those
make assumptions about locking. So we could pass a context through but per
Stephen's comment that gets a bit fragile. And sparse doesn't like it either
apparently. I think making it an explicit down/up reset callback might
make it clean and reusable for any other devices.
Any thoughts? My preference outside of open coding it is the new down_reset
and up_reset callbacks.
>
>> + if (ret) {
>> + netdev_warn(vi->dev, "virtio_finalize_features failed during reset aborting\n");
>> + goto err;
>> + }
>> +
>> + ret = init_vqs(vi);
>> + if (ret) {
>> + netdev_warn(vi->dev, "init_vqs failed during reset aborting\n");
>> + goto err;
>> + }
>> + virtio_device_ready(vi->vdev);
>> +
>> + if (netif_running(vi->dev)) {
>> + for (i = 0; i < vi->curr_queue_pairs; i++)
>> + if (!try_fill_recv(vi, &vi->rq[i], GFP_KERNEL))
>> + schedule_delayed_work(&vi->refill, 0);
>> +
>> + for (i = 0; i < vi->max_queue_pairs; i++)
>> + virtnet_napi_enable(&vi->rq[i]);
>> + }
>> + netif_device_attach(vi->dev);
>> + /* Finally, tell the device we're all set */
>> + status = vdev->config->get_status(vdev);
>> + vdev->config->set_status(vdev, status | VIRTIO_CONFIG_S_DRIVER_OK);
>> + virtio_config_enable(vdev);
>> +
>> + return 0;
>> +err:
>> + status = vdev->config->get_status(vdev);
>> + vdev->config->set_status(vdev, status | VIRTIO_CONFIG_S_FAILED);
>
> And maybe virtio_fail ?
>
Sure.
Thanks,
John
^ permalink raw reply
* Re: [net PATCH v3 3/5] virtio_net: factor out xdp handler for readability
From: John Fastabend @ 2017-01-13 19:56 UTC (permalink / raw)
To: Jason Wang, mst; +Cc: john.r.fastabend, netdev, alexei.starovoitov, daniel
In-Reply-To: <da246cbb-710c-275f-489c-251ea898a389@redhat.com>
On 17-01-12 11:40 PM, Jason Wang wrote:
>
>
> On 2017年01月13日 10:51, John Fastabend wrote:
>> At this point the do_xdp_prog is mostly if/else branches handling
>> the different modes of virtio_net. So remove it and handle running
>> the program in the per mode handlers.
>>
>> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
>> ---
>> drivers/net/virtio_net.c | 76 +++++++++++++++++-----------------------------
>> 1 file changed, 28 insertions(+), 48 deletions(-)
>>
>> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
>> index 43cb2e0..ec54644 100644
>> --- a/drivers/net/virtio_net.c
>> +++ b/drivers/net/virtio_net.c
>> @@ -388,49 +388,6 @@ static void virtnet_xdp_xmit(struct virtnet_info *vi,
>> virtqueue_kick(sq->vq);
>> }
>>
>
> [...]
>
>> /* This happens when rx buffer size is underestimated */
>> @@ -598,8 +570,10 @@ static struct sk_buff *receive_mergeable(struct
>> net_device *dev,
>> if (unlikely(hdr->hdr.gso_type))
>> goto err_xdp;
>> - act = do_xdp_prog(vi, rq, xdp_prog,
>> - page_address(xdp_page) + offset, len);
>> + data = page_address(xdp_page) + offset;
>> + xdp.data = data + desc_room;
>> + xdp.data_end = xdp.data + (len - vi->hdr_len);
>
> It looks desc_room is always vi->hdr_len.
>
Seems to be the case I'll just use vi->hdr_len and remove the variable.
Thanks.
>> + act = bpf_prog_run_xdp(xdp_prog, &xdp);
>> switch (act) {
>> case XDP_PASS:
>> /* We can only create skb based on xdp_page. */
>> @@ -613,13 +587,19 @@ static struct sk_buff *receive_mergeable(struct
>> net_device *dev,
>> }
>> break;
>> case XDP_TX:
>> + qp = vi->curr_queue_pairs -
>> + vi->xdp_queue_pairs +
>> + smp_processor_id();
>> + virtnet_xdp_xmit(vi, rq, &vi->sq[qp], &xdp, data);
>> ewma_pkt_len_add(&rq->mrg_avg_pkt_len, len);
>> if (unlikely(xdp_page != page))
>> goto err_xdp;
>> rcu_read_unlock();
>> goto xdp_xmit;
>> - case XDP_DROP:
>> default:
>> + bpf_warn_invalid_xdp_action(act);
>> + case XDP_ABORTED:
>> + case XDP_DROP:
>> if (unlikely(xdp_page != page))
>> __free_pages(xdp_page, 0);
>> ewma_pkt_len_add(&rq->mrg_avg_pkt_len, len);
>>
>
^ permalink raw reply
* ANNOUNCE: Netdev 2.1 in Montreal
From: Jamal Hadi Salim @ 2017-01-13 19:58 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA
Cc: netfilter-devel-u79uwXL29TY76Z2rM5mHXA,
netfilter-u79uwXL29TY76Z2rM5mHXA, info-Aq7fehzYRUagpaxmtUs7hg,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
tech-committee-Aq7fehzYRUagpaxmtUs7hg, David Miller,
Stephen Jaworski, Rob Echlin, lwn-T1hC0tSOHrs
Folks,
We are pleased to announce Netdev 2.1 (year 2, conference 1)
in the beautiful city of Montreal, Canada on the 6th to 8th of April.
The website is now online: http://www.netdevconf.org/2.1/
Netdev 2.1 will be held back to back with netconf2017.1
(http://vger.kernel.org/netconf2017.html)
Netdev 2.1 is a community-driven conference geared towards Linux
netheads. Linux kernel networking and user space utilization of the
interfaces to the Linux kernel networking subsystem are the central
theme.
If you are using Linux as a boot system for proprietary networking,
then this conference _may not be for you_.
Registration costs
------------------
Very Cheap.
$CAN 300 if you register before Feb 27. $360 after.
$CAN 150 if you are a student. $180 after Feb 27
Why you should register
-----------------------
If you yearn for the old community tech driven conferences where
you mingle with fellow geeks (only these would be Linux networking
geeks) then this would be it. There will be no marketing flashing
light openings or loud bad music. Just a pure feed of Linux
networking. Gurus and magicians of all sorts will be there mingling,
juggling and giving talks.
While there will be heavy Linux kernel influence we expect a lot
of user space presence as well.
Exact Location:
-----------------
Tentative: LE WESTIN MONTRÉAL
Sponsorship
------------
If you can help us organize this event by sponsoring, please drop us a
line to: sponsor-Aq7fehzYRUagpaxmtUs7hg@public.gmane.org and we'll send you our sponsorship policy.
Important dates
----------------
January 18, 2017 Call for proposals open
January 23, 2017 Registration opens
February 20, 2017 Call for proposals close
February 27, 2017 Early Registration close
March 13, 2017 Conference schedule announced
March 27, 2017 Paper submission
March 31, 2017 Online Registration close
April 3, 2017 Slides submission
April 6-8, 2017 Conference days
May 1, 2017 Slides release
June 1, 2017 Paper release
cheers,
jamal
^ permalink raw reply
* Re: [net PATCH v3 5/5] virtio_net: XDP support for adjust_head
From: John Fastabend @ 2017-01-13 20:08 UTC (permalink / raw)
To: Jason Wang, mst; +Cc: john.r.fastabend, netdev, alexei.starovoitov, daniel
In-Reply-To: <7c41d9b0-aa77-1485-4890-177ca7b01e50@redhat.com>
On 17-01-12 11:41 PM, Jason Wang wrote:
>
>
> On 2017年01月13日 10:52, John Fastabend wrote:
>> Add support for XDP adjust head by allocating a 256B header region
>> that XDP programs can grow into. This is only enabled when a XDP
>> program is loaded.
>>
>> In order to ensure that we do not have to unwind queue headroom push
>> queue setup below bpf_prog_add. It reads better to do a prog ref
>> unwind vs another queue setup call.
>>
>> At the moment this code must do a full reset to ensure old buffers
>> without headroom on program add or with headroom on program removal
>> are not used incorrectly in the datapath. Ideally we would only
>> have to disable/enable the RX queues being updated but there is no
>> API to do this at the moment in virtio so use the big hammer. In
>> practice it is likely not that big of a problem as this will only
>> happen when XDP is enabled/disabled changing programs does not
>> require the reset. There is some risk that the driver may either
>> have an allocation failure or for some reason fail to correctly
>> negotiate with the underlying backend in this case the driver will
>> be left uninitialized. I have not seen this ever happen on my test
>> systems and for what its worth this same failure case can occur
>> from probe and other contexts in virtio framework.
>>
>> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
>> ---
>> drivers/net/virtio_net.c | 155 ++++++++++++++++++++++++++++++++++++++++------
>> drivers/virtio/virtio.c | 9 ++-
>> include/linux/virtio.h | 3 +
>> 3 files changed, 144 insertions(+), 23 deletions(-)
>>
>> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
>> index 6041828..8b897e7 100644
>> --- a/drivers/net/virtio_net.c
>> +++ b/drivers/net/virtio_net.c
>> @@ -28,6 +28,7 @@
>> #include <linux/slab.h>
>> #include <linux/cpu.h>
>> #include <linux/average.h>
>> +#include <linux/pci.h>
>> #include <net/busy_poll.h>
>> static int napi_weight = NAPI_POLL_WEIGHT;
>> @@ -159,6 +160,9 @@ struct virtnet_info {
>> /* Ethtool settings */
>> u8 duplex;
>> u32 speed;
>> +
>> + /* Headroom allocated in RX Queue */
>> + unsigned int headroom;
>
> If this could not be changed in anyway, better use a macro instead of a filed
> here. And there's even no need to add an extra parameter to
> add_recvbuf_mergeable().
OK originally I thought this might be dynamic but I agree no need
for it here.
>
>> };
>> struct padded_vnet_hdr {
>> @@ -359,6 +363,7 @@ static void virtnet_xdp_xmit(struct virtnet_info *vi,
>> }
>> if (vi->mergeable_rx_bufs) {
>> + xdp->data -= sizeof(struct virtio_net_hdr_mrg_rxbuf);
>
> Fail to understand why this is needed. We should have excluded vnet header from
> xdp->data even before bpf_prog_run_xdp().
>
>> /* Zero header and leave csum up to XDP layers */
>> hdr = xdp->data;
>> memset(hdr, 0, vi->hdr_len);
>> @@ -375,7 +380,9 @@ static void virtnet_xdp_xmit(struct virtnet_info *vi,
>> num_sg = 2;
>> sg_init_table(sq->sg, 2);
>> sg_set_buf(sq->sg, hdr, vi->hdr_len);
>> - skb_to_sgvec(skb, sq->sg + 1, 0, skb->len);
>> + skb_to_sgvec(skb, sq->sg + 1,
>> + xdp->data - xdp->data_hard_start,
>> + xdp->data_end - xdp->data);
>> }
>> err = virtqueue_add_outbuf(sq->vq, sq->sg, num_sg,
>> data, GFP_ATOMIC);
>> @@ -401,7 +408,6 @@ static struct sk_buff *receive_small(struct net_device *dev,
>> struct bpf_prog *xdp_prog;
>> len -= vi->hdr_len;
>> - skb_trim(skb, len);
>> rcu_read_lock();
>> xdp_prog = rcu_dereference(rq->xdp_prog);
>> @@ -413,11 +419,15 @@ static struct sk_buff *receive_small(struct net_device
>> *dev,
>> if (unlikely(hdr->hdr.gso_type || hdr->hdr.flags))
>> goto err_xdp;
>> - xdp.data = skb->data;
>> + xdp.data_hard_start = skb->data;
>> + xdp.data = skb->data + vi->headroom;
>> xdp.data_end = xdp.data + len;
>> act = bpf_prog_run_xdp(xdp_prog, &xdp);
>> switch (act) {
>> case XDP_PASS:
>> + /* Recalculate length in case bpf program changed it */
>> + len = xdp.data_end - xdp.data;
>> + __skb_pull(skb, xdp.data - xdp.data_hard_start);
>
> How about do this just after bpf_pro_run_xdp() for XDP_TX too? This is more
> readable and there's no need to change xmit path.
Agreed will do.
>
>> break;
>> case XDP_TX:
>> virtnet_xdp_xmit(vi, rq, &xdp, skb);
>> @@ -432,6 +442,7 @@ static struct sk_buff *receive_small(struct net_device *dev,
>> }
>> rcu_read_unlock();
>> + skb_trim(skb, len);
>> return skb;
>> err_xdp:
>> @@ -569,7 +580,11 @@ static struct sk_buff *receive_mergeable(struct
>> net_device *dev,
>> if (unlikely(hdr->hdr.gso_type))
>> goto err_xdp;
>> + /* Allow consuming headroom but reserve enough space to push
>> + * the descriptor on if we get an XDP_TX return code.
>> + */
>> data = page_address(xdp_page) + offset;
>> + xdp.data_hard_start = data - vi->headroom + desc_room;
>
> Two possible issues here:
>
> 1) If we want to adjust header after linearizing, we should reserve a room for
> that page, but I don't see any codes for this.
> 2) If the header has been adjusted, looks like we need change offset value
> otherwise, page_to_skb() won't build a correct skb for us for XDP_PASS.
>
Both correct thanks. I'll add a couple sample programs to catch this as well.
>> xdp.data = data + desc_room;
>> xdp.data_end = xdp.data + (len - vi->hdr_len);
>> act = bpf_prog_run_xdp(xdp_prog, &xdp);
>> @@ -748,20 +763,21 @@ static void receive_buf(struct virtnet_info *vi, struct
>> receive_queue *rq,
>> static int add_recvbuf_small(struct virtnet_info *vi, struct receive_queue *rq,
>> gfp_t gfp)
>> {
>> + int headroom = GOOD_PACKET_LEN + vi->headroom;
>> struct sk_buff *skb;
>> struct virtio_net_hdr_mrg_rxbuf *hdr;
>> int err;
>> - skb = __netdev_alloc_skb_ip_align(vi->dev, GOOD_PACKET_LEN, gfp);
>> + skb = __netdev_alloc_skb_ip_align(vi->dev, headroom, gfp);
>> if (unlikely(!skb))
>> return -ENOMEM;
>> - skb_put(skb, GOOD_PACKET_LEN);
>> + skb_put(skb, headroom);
>> hdr = skb_vnet_hdr(skb);
>> sg_init_table(rq->sg, 2);
>> sg_set_buf(rq->sg, hdr, vi->hdr_len);
>> - skb_to_sgvec(skb, rq->sg + 1, 0, skb->len);
>> + skb_to_sgvec(skb, rq->sg + 1, vi->headroom, skb->len - vi->headroom);
>> err = virtqueue_add_inbuf(rq->vq, rq->sg, 2, skb, gfp);
>> if (err < 0)
>> @@ -829,24 +845,27 @@ static unsigned int get_mergeable_buf_len(struct
>> ewma_pkt_len *avg_pkt_len)
>> return ALIGN(len, MERGEABLE_BUFFER_ALIGN);
>> }
>> -static int add_recvbuf_mergeable(struct receive_queue *rq, gfp_t gfp)
>> +static int add_recvbuf_mergeable(struct virtnet_info *vi,
>> + struct receive_queue *rq, gfp_t gfp)
>> {
>> struct page_frag *alloc_frag = &rq->alloc_frag;
>> + unsigned int headroom = vi->headroom;
>> char *buf;
>> unsigned long ctx;
>> int err;
>> unsigned int len, hole;
>> len = get_mergeable_buf_len(&rq->mrg_avg_pkt_len);
>> - if (unlikely(!skb_page_frag_refill(len, alloc_frag, gfp)))
>> + if (unlikely(!skb_page_frag_refill(len + headroom, alloc_frag, gfp)))
>> return -ENOMEM;
>> buf = (char *)page_address(alloc_frag->page) + alloc_frag->offset;
>> + buf += headroom; /* advance address leaving hole at front of pkt */
>> ctx = mergeable_buf_to_ctx(buf, len);
>> get_page(alloc_frag->page);
>> - alloc_frag->offset += len;
>> + alloc_frag->offset += len + headroom;
>> hole = alloc_frag->size - alloc_frag->offset;
>> - if (hole < len) {
>> + if (hole < len + headroom) {
>> /* To avoid internal fragmentation, if there is very likely not
>> * enough space for another buffer, add the remaining space to
>> * the current buffer. This extra space is not included in
>> @@ -880,7 +899,7 @@ static bool try_fill_recv(struct virtnet_info *vi, struct
>> receive_queue *rq,
>> gfp |= __GFP_COLD;
>> do {
>> if (vi->mergeable_rx_bufs)
>> - err = add_recvbuf_mergeable(rq, gfp);
>> + err = add_recvbuf_mergeable(vi, rq, gfp);
>> else if (vi->big_packets)
>> err = add_recvbuf_big(vi, rq, gfp);
>> else
>> @@ -1675,12 +1694,90 @@ static void virtnet_init_settings(struct net_device *dev)
>> .set_settings = virtnet_set_settings,
>> };
>> +#define VIRTIO_XDP_HEADROOM 256
>> +
>> +static int init_vqs(struct virtnet_info *vi);
>> +static void remove_vq_common(struct virtnet_info *vi, bool lock);
>> +
>> +/* Reset virtio device with RTNL held this is very similar to the
>> + * freeze()/restore() logic except we need to ensure locking. It is
>> + * possible that this routine may fail and leave the driver in a
>> + * failed state. However assuming the driver negotiated correctly
>> + * at probe time we _should_ be able to (re)negotiate driver again.
>> + */
>
> Instead of duplicate codes and export helpers, why not use
> virtio_device_freeze()/virtio_device_restore()? For rtnl_lock in restore, you
> can probably avoid it be checking rtnl_is_locked() before?
freeze/restore does virtnet_cpu_notif_* work that is not needed
in this case. But the overhead here is maybe minimal.
Michael wanted to create a generic virtio_reset() so let me
give that a try and that should clean this up as well.
.John
>
>> +static int virtnet_xdp_reset(struct virtnet_info *vi)
>> +{
>> + struct virtio_device *vdev = vi->vdev;
>> + unsigned int status;
>> + int i, ret;
>> +
>> + /* Disable and unwind rings */
>> + virtio_config_disable(vdev);
>> + vdev->failed = vdev->config->get_status(vdev) & VIRTIO_CONFIG_S_FAILED;
>> +
>> + netif_device_detach(vi->dev);
>> + cancel_delayed_work_sync(&vi->refill);
>> + if (netif_running(vi->dev)) {
>> + for (i = 0; i < vi->max_queue_pairs; i++)
>> + napi_disable(&vi->rq[i].napi);
>> + }
>> +
>> + remove_vq_common(vi, false);
>> +
>> + /* Do a reset per virtio spec recommendation */
>> + vdev->config->reset(vdev);
>> +
>> + /* Acknowledge that we've seen the device. */
>> + status = vdev->config->get_status(vdev);
>> + vdev->config->set_status(vdev, status | VIRTIO_CONFIG_S_ACKNOWLEDGE);
>> +
>> + /* Notify driver is up and finalize features per specification. The
>> + * error code from finalize features is checked here but should not
>> + * fail because we assume features were previously synced successfully.
>> + */
>> + status = vdev->config->get_status(vdev);
>> + vdev->config->set_status(vdev, status | VIRTIO_CONFIG_S_DRIVER);
>> + ret = virtio_finalize_features(vdev);
>> + if (ret) {
>> + netdev_warn(vi->dev, "virtio_finalize_features failed during reset
>> aborting\n");
>> + goto err;
>> + }
>> +
>> + ret = init_vqs(vi);
>> + if (ret) {
>> + netdev_warn(vi->dev, "init_vqs failed during reset aborting\n");
>> + goto err;
>> + }
>> + virtio_device_ready(vi->vdev);
>> +
>> + if (netif_running(vi->dev)) {
>> + for (i = 0; i < vi->curr_queue_pairs; i++)
>> + if (!try_fill_recv(vi, &vi->rq[i], GFP_KERNEL))
>> + schedule_delayed_work(&vi->refill, 0);
>> +
>> + for (i = 0; i < vi->max_queue_pairs; i++)
>> + virtnet_napi_enable(&vi->rq[i]);
>> + }
>> + netif_device_attach(vi->dev);
>> + /* Finally, tell the device we're all set */
>> + status = vdev->config->get_status(vdev);
>> + vdev->config->set_status(vdev, status | VIRTIO_CONFIG_S_DRIVER_OK);
>> + virtio_config_enable(vdev);
>> +
>> + return 0;
>> +err:
>> + status = vdev->config->get_status(vdev);
>> + vdev->config->set_status(vdev, status | VIRTIO_CONFIG_S_FAILED);
>> + return ret;
>> +}
>
> [...]
^ permalink raw reply
* Re: [PATCH 1/3] powerpc: bpf: remove redundant check for non-null image
From: Alexei Starovoitov @ 2017-01-13 20:09 UTC (permalink / raw)
To: Naveen N. Rao; +Cc: mpe, linuxppc-dev, netdev, ast, daniel, davem
In-Reply-To: <e73efe6facf6c06932b4a87707e5978172ee773e.1484326337.git.naveen.n.rao@linux.vnet.ibm.com>
On Fri, Jan 13, 2017 at 10:40:00PM +0530, Naveen N. Rao wrote:
> From: Daniel Borkmann <daniel@iogearbox.net>
>
> We have a check earlier to ensure we don't proceed if image is NULL. As
> such, the redundant check can be removed.
>
> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
> [Added similar changes for classic BPF JIT]
> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
^ permalink raw reply
* Re: [PATCH 2/3] powerpc: bpf: flush the entire JIT buffer
From: Alexei Starovoitov @ 2017-01-13 20:10 UTC (permalink / raw)
To: Naveen N. Rao; +Cc: mpe, linuxppc-dev, netdev, ast, daniel, davem
In-Reply-To: <897d01cca8cd61a42493a4f6ba6bfca056419686.1484326337.git.naveen.n.rao@linux.vnet.ibm.com>
On Fri, Jan 13, 2017 at 10:40:01PM +0530, Naveen N. Rao wrote:
> With bpf_jit_binary_alloc(), we allocate at a page granularity and fill
> the rest of the space with illegal instructions to mitigate BPF spraying
> attacks, while having the actual JIT'ed BPF program at a random location
> within the allocated space. Under this scenario, it would be better to
> flush the entire allocated buffer rather than just the part containing
> the actual program. We already flush the buffer from start to the end of
> the BPF program. Extend this to include the illegal instructions after
> the BPF program.
>
> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
^ permalink raw reply
* [PATCH net-next] sctp: remove dead code from sctp_apply_peer_addr_params
From: Marcelo Ricardo Leitner @ 2017-01-13 20:27 UTC (permalink / raw)
To: netdev; +Cc: linux-sctp, Vlad Yasevich, Neil Horman
sctp_frag_point() doesn't store anything, and thus just calling it
cannot do anything useful.
sctp_apply_peer_addr_params is only called by
sctp_setsockopt_peer_addr_params. When operating on an asoc,
sctp_setsockopt_peer_addr_params will call sctp_apply_peer_addr_params
once for the asoc, and then once for each transport this asoc has,
meaning that the frag_point will be recomputed when updating the
transports and calling it when updating the asoc is not necessary.
IOW, no action is needed here and we can remove this call.
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
---
net/sctp/socket.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 318c6786d6539a301ac7b76d82a49a1af3818d10..635e0341269330187c78ba93a35689f5c5d6be02 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -2430,7 +2430,6 @@ static int sctp_apply_peer_addr_params(struct sctp_paddrparams *params,
sctp_assoc_sync_pmtu(sctp_opt2sk(sp), asoc);
} else if (asoc) {
asoc->pathmtu = params->spp_pathmtu;
- sctp_frag_point(asoc, params->spp_pathmtu);
} else {
sp->pathmtu = params->spp_pathmtu;
}
--
2.9.3
^ permalink raw reply related
* [PATCH net-next] sctp: remove unused var from sctp_process_asconf
From: Marcelo Ricardo Leitner @ 2017-01-13 20:27 UTC (permalink / raw)
To: netdev; +Cc: linux-sctp, Vlad Yasevich, Neil Horman
Assigned but not used.
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
---
net/sctp/sm_make_chunk.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
index a15d824a313d310ed03ba77055d22b1c7c9d0662..80a9088084ac0d1116bf983fad9a0cdfddeefe44 100644
--- a/net/sctp/sm_make_chunk.c
+++ b/net/sctp/sm_make_chunk.c
@@ -3210,7 +3210,6 @@ struct sctp_chunk *sctp_process_asconf(struct sctp_association *asoc,
union sctp_params param;
sctp_addiphdr_t *hdr;
union sctp_addr_param *addr_param;
- sctp_addip_param_t *asconf_param;
struct sctp_chunk *asconf_ack;
__be16 err_code;
int length = 0;
@@ -3230,7 +3229,6 @@ struct sctp_chunk *sctp_process_asconf(struct sctp_association *asoc,
* asconf parameter.
*/
length = ntohs(addr_param->p.length);
- asconf_param = (void *)addr_param + length;
chunk_len -= length;
/* create an ASCONF_ACK chunk.
--
2.9.3
^ permalink raw reply related
* Re: [pull request][for-next] Mellanox mlx5 Reorganize core driver directory layout
From: Leon Romanovsky @ 2017-01-13 20:29 UTC (permalink / raw)
To: David Miller; +Cc: saeedm, dledford, netdev, linux-rdma
In-Reply-To: <20170113.121407.448230751444957957.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 2092 bytes --]
On Fri, Jan 13, 2017 at 12:14:07PM -0500, David Miller wrote:
> From: Saeed Mahameed <saeedm@mellanox.com>
> Date: Thu, 12 Jan 2017 19:22:34 +0200
>
> > This pull request includes one patch from Leon, this patch as described
> > below will change the driver directory structure and layout for better,
> > logical and modular driver files separation.
> >
> > This change is important to both rdma and net maintainers in order to
> > have smoother management of driver patches for different mlx5 sub modules
> > and smoother rdma-next vs. net-next features submissions.
> >
> > Please find more info below -in the tag commit message-,
> > review and let us know if there's any problem.
> >
> > This change doesn't introduce any conflicts with the current mlx5
> > fixes and cleanups posted on 2017-01-10 to net branch, and merge tests
> > worked flawlessly with no issues.
> >
> > This is the last pull request meant for both rdma-next and net-next.
> > Once pulled, this will be the base shared code for both trees.
>
> This is pretty crazy, it will make all bug fix backporting to -stable
> a complete nightmare for myself, Doug, various distribution maintainers
> and many other people who quietly have to maintain their own trees and
> do backporting.
Hi Dave,
I understand your worries, but our case is similar to various other
drivers, for example hfi1 which was in staging for years while
supported in RedHat and moved from there to IB. The Chelsio drivers did
similar reorg in 2016 (drivers/net/ethernet/chelsio/libcxgb) while their
drivers were in the tree for long time before.
Additionally, Doug doesn't need to maintain -stable queue and it is done
by relevant submaintainers who are adding stable tags by themselves. In
the IB case, the burden will continue to be on me and not on Doug.
>
> I really don't think you can justify this rearrangement based upon the
> consequences and how much activity happens in this driver.
>
> You should have thought long and hard about the layout a long time ago
> rather than after the driver has been in the tree for many years.
>
> Sorry.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] sctp: remove dead code from sctp_apply_peer_addr_params
From: Marcelo Ricardo Leitner @ 2017-01-13 20:30 UTC (permalink / raw)
To: netdev; +Cc: linux-sctp, Vlad Yasevich, Neil Horman
In-Reply-To: <99bc9f227c4c857d2bb25839a6a8341d46c1899d.1484336556.git.marcelo.leitner@gmail.com>
On Fri, Jan 13, 2017 at 06:27:32PM -0200, Marcelo Ricardo Leitner wrote:
> sctp_frag_point() doesn't store anything, and thus just calling it
> cannot do anything useful.
Please ignore this one. Will post another one with
s/dead code/useless code/ , as the code not really dead..
>
> sctp_apply_peer_addr_params is only called by
> sctp_setsockopt_peer_addr_params. When operating on an asoc,
> sctp_setsockopt_peer_addr_params will call sctp_apply_peer_addr_params
> once for the asoc, and then once for each transport this asoc has,
> meaning that the frag_point will be recomputed when updating the
> transports and calling it when updating the asoc is not necessary.
> IOW, no action is needed here and we can remove this call.
>
> Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
> ---
> net/sctp/socket.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index 318c6786d6539a301ac7b76d82a49a1af3818d10..635e0341269330187c78ba93a35689f5c5d6be02 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -2430,7 +2430,6 @@ static int sctp_apply_peer_addr_params(struct sctp_paddrparams *params,
> sctp_assoc_sync_pmtu(sctp_opt2sk(sp), asoc);
> } else if (asoc) {
> asoc->pathmtu = params->spp_pathmtu;
> - sctp_frag_point(asoc, params->spp_pathmtu);
> } else {
> sp->pathmtu = params->spp_pathmtu;
> }
> --
> 2.9.3
>
> --
> 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
* [PATCH net-next] sctp: remove useless code from sctp_apply_peer_addr_params
From: Marcelo Ricardo Leitner @ 2017-01-13 20:31 UTC (permalink / raw)
To: netdev; +Cc: linux-sctp, Vlad Yasevich, Neil Horman
sctp_frag_point() doesn't store anything, and thus just calling it
cannot do anything useful.
sctp_apply_peer_addr_params is only called by
sctp_setsockopt_peer_addr_params. When operating on an asoc,
sctp_setsockopt_peer_addr_params will call sctp_apply_peer_addr_params
once for the asoc, and then once for each transport this asoc has,
meaning that the frag_point will be recomputed when updating the
transports and calling it when updating the asoc is not necessary.
IOW, no action is needed here and we can remove this call.
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
---
net/sctp/socket.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 318c6786d6539a301ac7b76d82a49a1af3818d10..635e0341269330187c78ba93a35689f5c5d6be02 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -2430,7 +2430,6 @@ static int sctp_apply_peer_addr_params(struct sctp_paddrparams *params,
sctp_assoc_sync_pmtu(sctp_opt2sk(sp), asoc);
} else if (asoc) {
asoc->pathmtu = params->spp_pathmtu;
- sctp_frag_point(asoc, params->spp_pathmtu);
} else {
sp->pathmtu = params->spp_pathmtu;
}
--
2.9.3
^ permalink raw reply related
* [PATCH net-next 0/2] sfc: TX PIO fixes
From: Edward Cree @ 2017-01-13 21:18 UTC (permalink / raw)
To: linux-net-drivers, davem; +Cc: netdev
Edward Cree (2):
sfc: allow PIO more often
sfc: get PIO buffer size from the NIC
drivers/net/ethernet/sfc/ef10.c | 21 +++++++++++++++------
drivers/net/ethernet/sfc/net_driver.h | 9 +++++++++
drivers/net/ethernet/sfc/nic.h | 19 ++++++++++++++++---
drivers/net/ethernet/sfc/siena.c | 1 +
drivers/net/ethernet/sfc/tx.c | 2 +-
5 files changed, 42 insertions(+), 10 deletions(-)
^ permalink raw reply
* [PATCH net-next 1/2] sfc: allow PIO more often
From: Edward Cree @ 2017-01-13 21:20 UTC (permalink / raw)
To: linux-net-drivers, davem; +Cc: netdev
In-Reply-To: <eae20bb1-89d4-0e81-6c56-0c7058d06ada@solarflare.com>
If an option descriptor has been sent on a queue but not followed by a
packet, there will have been no completion event, so the read and write
counts won't match and we'll think we can't do PIO. This combines with
the fact that we have two TX queues (for en/disable checksum offload),
and that both must be empty for PIO to happen.
This patch adds a separate "packet_write_count" that tracks the most
recent write_count we expect to see a completion event for; this excludes
option descriptors but _includes_ PIO descriptors (even though they look
like option descriptors). This is then used, rather than write_count,
in efx_nic_tx_is_empty().
We only bother to maintain packet_write_count on EF10, since on Siena
(a) there are no option descriptors and it always equals write_count, and
(b) there's no PIO, so we don't need it anyway.
Signed-off-by: Edward Cree <ecree@solarflare.com>
---
drivers/net/ethernet/sfc/ef10.c | 5 +++++
drivers/net/ethernet/sfc/net_driver.h | 9 +++++++++
drivers/net/ethernet/sfc/nic.h | 17 ++++++++++++++---
drivers/net/ethernet/sfc/siena.c | 1 +
drivers/net/ethernet/sfc/tx.c | 1 +
5 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/sfc/ef10.c b/drivers/net/ethernet/sfc/ef10.c
index 208e004..f6e29a9 100644
--- a/drivers/net/ethernet/sfc/ef10.c
+++ b/drivers/net/ethernet/sfc/ef10.c
@@ -2358,7 +2358,11 @@ static void efx_ef10_tx_write(struct efx_tx_queue *tx_queue)
/* Create TX descriptor ring entry */
if (buffer->flags & EFX_TX_BUF_OPTION) {
*txd = buffer->option;
+ if (EFX_QWORD_FIELD(*txd, ESF_DZ_TX_OPTION_TYPE) == 1)
+ /* PIO descriptor */
+ tx_queue->packet_write_count = tx_queue->write_count;
} else {
+ tx_queue->packet_write_count = tx_queue->write_count;
BUILD_BUG_ON(EFX_TX_BUF_CONT != 1);
EFX_POPULATE_QWORD_3(
*txd,
@@ -5796,6 +5800,7 @@ const struct efx_nic_type efx_hunt_a0_nic_type = {
.rx_ts_offset = ES_DZ_RX_PREFIX_TSTAMP_OFST,
.can_rx_scatter = true,
.always_rx_scatter = true,
+ .option_descriptors = true,
.max_interrupt_mode = EFX_INT_MODE_MSIX,
.timer_period_max = 1 << ERF_DD_EVQ_IND_TIMER_VAL_WIDTH,
.offload_features = EF10_OFFLOAD_FEATURES,
diff --git a/drivers/net/ethernet/sfc/net_driver.h b/drivers/net/ethernet/sfc/net_driver.h
index 49db9e8..b20fe43 100644
--- a/drivers/net/ethernet/sfc/net_driver.h
+++ b/drivers/net/ethernet/sfc/net_driver.h
@@ -208,6 +208,12 @@ struct efx_tx_buffer {
* @write_count: Current write pointer
* This is the number of buffers that have been added to the
* hardware ring.
+ * @packet_write_count: Completable write pointer
+ * This is the write pointer of the last packet written.
+ * Normally this will equal @write_count, but as option descriptors
+ * don't produce completion events, they won't update this.
+ * Filled in iff @efx->type->option_descriptors; only used for PIO.
+ * Thus, this is written and used on EF10, and neither on farch.
* @old_read_count: The value of read_count when last checked.
* This is here for performance reasons. The xmit path will
* only get the up-to-date value of read_count if this
@@ -255,6 +261,7 @@ struct efx_tx_queue {
/* Members used only on the xmit path */
unsigned int insert_count ____cacheline_aligned_in_smp;
unsigned int write_count;
+ unsigned int packet_write_count;
unsigned int old_read_count;
unsigned int tso_bursts;
unsigned int tso_long_headers;
@@ -1237,6 +1244,7 @@ struct efx_mtd_partition {
* @rx_buffer_padding: Size of padding at end of RX packet
* @can_rx_scatter: NIC is able to scatter packets to multiple buffers
* @always_rx_scatter: NIC will always scatter packets to multiple buffers
+ * @option_descriptors: NIC supports TX option descriptors
* @max_interrupt_mode: Highest capability interrupt mode supported
* from &enum efx_init_mode.
* @timer_period_max: Maximum period of interrupt timer (in ticks)
@@ -1395,6 +1403,7 @@ struct efx_nic_type {
unsigned int rx_buffer_padding;
bool can_rx_scatter;
bool always_rx_scatter;
+ bool option_descriptors;
unsigned int max_interrupt_mode;
unsigned int timer_period_max;
netdev_features_t offload_features;
diff --git a/drivers/net/ethernet/sfc/nic.h b/drivers/net/ethernet/sfc/nic.h
index 2237746..6a69aa3 100644
--- a/drivers/net/ethernet/sfc/nic.h
+++ b/drivers/net/ethernet/sfc/nic.h
@@ -85,6 +85,17 @@ static inline bool __efx_nic_tx_is_empty(struct efx_tx_queue *tx_queue,
return ((empty_read_count ^ write_count) & ~EFX_EMPTY_COUNT_VALID) == 0;
}
+/* Report whether the NIC considers this TX queue empty, using
+ * packet_write_count (the write count recorded for the last completable
+ * doorbell push). May return false negative. EF10 only, which is OK
+ * because only EF10 supports PIO.
+ */
+static inline bool efx_nic_tx_is_empty(struct efx_tx_queue *tx_queue)
+{
+ EFX_WARN_ON_ONCE_PARANOID(!tx_queue->efx->type->option_descriptors);
+ return __efx_nic_tx_is_empty(tx_queue, tx_queue->packet_write_count);
+}
+
/* Decide whether we can use TX PIO, ie. write packet data directly into
* a buffer on the device. This can reduce latency at the expense of
* throughput, so we only do this if both hardware and software TX rings
@@ -94,9 +105,9 @@ static inline bool __efx_nic_tx_is_empty(struct efx_tx_queue *tx_queue,
static inline bool efx_nic_may_tx_pio(struct efx_tx_queue *tx_queue)
{
struct efx_tx_queue *partner = efx_tx_queue_partner(tx_queue);
- return tx_queue->piobuf &&
- __efx_nic_tx_is_empty(tx_queue, tx_queue->insert_count) &&
- __efx_nic_tx_is_empty(partner, partner->insert_count);
+
+ return tx_queue->piobuf && efx_nic_tx_is_empty(tx_queue) &&
+ efx_nic_tx_is_empty(partner);
}
/* Decide whether to push a TX descriptor to the NIC vs merely writing
diff --git a/drivers/net/ethernet/sfc/siena.c b/drivers/net/ethernet/sfc/siena.c
index 4e54e5d..118ff56 100644
--- a/drivers/net/ethernet/sfc/siena.c
+++ b/drivers/net/ethernet/sfc/siena.c
@@ -1044,6 +1044,7 @@ const struct efx_nic_type siena_a0_nic_type = {
.rx_hash_offset = FS_BZ_RX_PREFIX_HASH_OFST,
.rx_buffer_padding = 0,
.can_rx_scatter = true,
+ .option_descriptors = false,
.max_interrupt_mode = EFX_INT_MODE_MSIX,
.timer_period_max = 1 << FRF_CZ_TC_TIMER_VAL_WIDTH,
.offload_features = (NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM |
diff --git a/drivers/net/ethernet/sfc/tx.c b/drivers/net/ethernet/sfc/tx.c
index 3c01514..beaf980 100644
--- a/drivers/net/ethernet/sfc/tx.c
+++ b/drivers/net/ethernet/sfc/tx.c
@@ -817,6 +817,7 @@ void efx_init_tx_queue(struct efx_tx_queue *tx_queue)
tx_queue->insert_count = 0;
tx_queue->write_count = 0;
+ tx_queue->packet_write_count = 0;
tx_queue->old_write_count = 0;
tx_queue->read_count = 0;
tx_queue->old_read_count = 0;
^ permalink raw reply related
* [PATCH net-next 2/2] sfc: get PIO buffer size from the NIC
From: Edward Cree @ 2017-01-13 21:20 UTC (permalink / raw)
To: linux-net-drivers, davem; +Cc: netdev
In-Reply-To: <eae20bb1-89d4-0e81-6c56-0c7058d06ada@solarflare.com>
The 8000 series SFC NICs have 4K PIO buffers, rather than the 2K of
the 7000 series. Rather than having a hard-coded PIO buffer size
(ER_DZ_TX_PIOBUF_SIZE), read it from the GET_CAPABILITIES_V2 MCDI
response.
Signed-off-by: Edward Cree <ecree@solarflare.com>
---
drivers/net/ethernet/sfc/ef10.c | 16 ++++++++++------
drivers/net/ethernet/sfc/nic.h | 2 ++
drivers/net/ethernet/sfc/tx.c | 1 -
3 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/sfc/ef10.c b/drivers/net/ethernet/sfc/ef10.c
index f6e29a9..2ce5769 100644
--- a/drivers/net/ethernet/sfc/ef10.c
+++ b/drivers/net/ethernet/sfc/ef10.c
@@ -197,11 +197,15 @@ static int efx_ef10_init_datapath_caps(struct efx_nic *efx)
nic_data->datapath_caps =
MCDI_DWORD(outbuf, GET_CAPABILITIES_OUT_FLAGS1);
- if (outlen >= MC_CMD_GET_CAPABILITIES_V2_OUT_LEN)
+ if (outlen >= MC_CMD_GET_CAPABILITIES_V2_OUT_LEN) {
nic_data->datapath_caps2 = MCDI_DWORD(outbuf,
GET_CAPABILITIES_V2_OUT_FLAGS2);
- else
+ nic_data->piobuf_size = MCDI_WORD(outbuf,
+ GET_CAPABILITIES_V2_OUT_SIZE_PIO_BUFF);
+ } else {
nic_data->datapath_caps2 = 0;
+ nic_data->piobuf_size = ER_DZ_TX_PIOBUF_SIZE;
+ }
/* record the DPCPU firmware IDs to determine VEB vswitching support.
*/
@@ -823,8 +827,8 @@ static int efx_ef10_link_piobufs(struct efx_nic *efx)
offset = ((efx->tx_channel_offset + efx->n_tx_channels -
tx_queue->channel->channel - 1) *
efx_piobuf_size);
- index = offset / ER_DZ_TX_PIOBUF_SIZE;
- offset = offset % ER_DZ_TX_PIOBUF_SIZE;
+ index = offset / nic_data->piobuf_size;
+ offset = offset % nic_data->piobuf_size;
/* When the host page size is 4K, the first
* host page in the WC mapping may be within
@@ -1159,11 +1163,11 @@ static int efx_ef10_dimension_resources(struct efx_nic *efx)
* functions of the controller.
*/
if (efx_piobuf_size != 0 &&
- ER_DZ_TX_PIOBUF_SIZE / efx_piobuf_size * EF10_TX_PIOBUF_COUNT >=
+ nic_data->piobuf_size / efx_piobuf_size * EF10_TX_PIOBUF_COUNT >=
efx->n_tx_channels) {
unsigned int n_piobufs =
DIV_ROUND_UP(efx->n_tx_channels,
- ER_DZ_TX_PIOBUF_SIZE / efx_piobuf_size);
+ nic_data->piobuf_size / efx_piobuf_size);
rc = efx_ef10_alloc_piobufs(efx, n_piobufs);
if (rc)
diff --git a/drivers/net/ethernet/sfc/nic.h b/drivers/net/ethernet/sfc/nic.h
index 6a69aa3..383ff6e 100644
--- a/drivers/net/ethernet/sfc/nic.h
+++ b/drivers/net/ethernet/sfc/nic.h
@@ -343,6 +343,7 @@ enum {
* @pio_write_base: Base address for writing PIO buffers
* @pio_write_vi_base: Relative VI number for @pio_write_base
* @piobuf_handle: Handle of each PIO buffer allocated
+ * @piobuf_size: size of a single PIO buffer
* @must_restore_piobufs: Flag: PIO buffers have yet to be restored after MC
* reboot
* @rx_rss_context: Firmware handle for our RSS context
@@ -380,6 +381,7 @@ struct efx_ef10_nic_data {
void __iomem *wc_membase, *pio_write_base;
unsigned int pio_write_vi_base;
unsigned int piobuf_handle[EF10_TX_PIOBUF_COUNT];
+ u16 piobuf_size;
bool must_restore_piobufs;
u32 rx_rss_context;
bool rx_rss_context_exclusive;
diff --git a/drivers/net/ethernet/sfc/tx.c b/drivers/net/ethernet/sfc/tx.c
index beaf980..ff88d60 100644
--- a/drivers/net/ethernet/sfc/tx.c
+++ b/drivers/net/ethernet/sfc/tx.c
@@ -28,7 +28,6 @@
#ifdef EFX_USE_PIO
-#define EFX_PIOBUF_SIZE_MAX ER_DZ_TX_PIOBUF_SIZE
#define EFX_PIOBUF_SIZE_DEF ALIGN(256, L1_CACHE_BYTES)
unsigned int efx_piobuf_size __read_mostly = EFX_PIOBUF_SIZE_DEF;
^ permalink raw reply related
* Re: kill off pci_enable_msi_{exact,range}
From: Tom Lendacky @ 2017-01-13 21:28 UTC (permalink / raw)
To: Christoph Hellwig, Bjorn Helgaas
Cc: linux-pci, Mauro Carvalho Chehab, netdev, linux-media
In-Reply-To: <20170113171519.GA5857@lst.de>
On 1/13/2017 11:15 AM, Christoph Hellwig wrote:
> On Fri, Jan 13, 2017 at 11:13:21AM -0600, Bjorn Helgaas wrote:
>> I dropped the empty commit and replaced the xgbe patch with the one below.
>> Can you take a look at [1] and make sure it's what you expected?
>
> This looks great, thanks!
>
Christoph and Bjorn, thanks for taking care of this!
Tom
^ permalink raw reply
* [PATCH net 1/3] be2net: fix status check in be_cmd_pmac_add()
From: Ivan Vecera @ 2017-01-13 21:38 UTC (permalink / raw)
To: netdev; +Cc: Sathya Perla, Ajit Khaparde, Sriharsha Basavapatna, Somnath Kotur
Return value from be_mcc_notify_wait() contains a base completion status
together with an additional status. The base_status() macro need to be
used to access base status.
Fixes: e3a7ae2 be2net: Changing MAC Address of a VF was broken
Cc: Sathya Perla <sathya.perla@broadcom.com>
Cc: Ajit Khaparde <ajit.khaparde@broadcom.com>
Cc: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
Cc: Somnath Kotur <somnath.kotur@broadcom.com>
Signed-off-by: Ivan Vecera <cera@cera.cz>
---
drivers/net/ethernet/emulex/benet/be_cmds.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_cmds.c b/drivers/net/ethernet/emulex/benet/be_cmds.c
index 0e74529..30e8550 100644
--- a/drivers/net/ethernet/emulex/benet/be_cmds.c
+++ b/drivers/net/ethernet/emulex/benet/be_cmds.c
@@ -1118,7 +1118,7 @@ int be_cmd_pmac_add(struct be_adapter *adapter, u8 *mac_addr,
err:
mutex_unlock(&adapter->mcc_lock);
- if (status == MCC_STATUS_UNAUTHORIZED_REQUEST)
+ if (base_status(status) == MCC_STATUS_UNAUTHORIZED_REQUEST)
status = -EPERM;
return status;
--
2.10.2
^ permalink raw reply related
* [PATCH net 2/3] be2net: don't delete MAC on close on unprivileged BE3 VFs
From: Ivan Vecera @ 2017-01-13 21:38 UTC (permalink / raw)
To: netdev; +Cc: Sathya Perla, Ajit Khaparde, Sriharsha Basavapatna, Somnath Kotur
In-Reply-To: <20170113213829.22722-1-cera@cera.cz>
BE3 VFs without FILTMGMT privilege are not allowed to modify its MAC,
VLAN table and UC/MC lists. So don't try to delete MAC on such VFs.
Cc: Sathya Perla <sathya.perla@broadcom.com>
Cc: Ajit Khaparde <ajit.khaparde@broadcom.com>
Cc: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
Cc: Somnath Kotur <somnath.kotur@broadcom.com>
Signed-off-by: Ivan Vecera <cera@cera.cz>
---
drivers/net/ethernet/emulex/benet/be_main.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index ec010ce..d606e20 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -3609,7 +3609,11 @@ static void be_rx_qs_destroy(struct be_adapter *adapter)
static void be_disable_if_filters(struct be_adapter *adapter)
{
- be_dev_mac_del(adapter, adapter->pmac_id[0]);
+ /* Don't delete MAC on BE3 VFs without FILTMGMT privilege */
+ if (!BEx_chip(adapter) || !be_virtfn(adapter) ||
+ check_privilege(adapter, BE_PRIV_FILTMGMT))
+ be_dev_mac_del(adapter, adapter->pmac_id[0]);
+
be_clear_uc_list(adapter);
be_clear_mc_list(adapter);
--
2.10.2
^ permalink raw reply related
* [PATCH net 3/3] be2net: fix MAC addr setting on privileged BE3 VFs
From: Ivan Vecera @ 2017-01-13 21:38 UTC (permalink / raw)
To: netdev; +Cc: Sathya Perla, Ajit Khaparde, Sriharsha Basavapatna, Somnath Kotur
In-Reply-To: <20170113213829.22722-1-cera@cera.cz>
During interface opening MAC address stored in netdev->dev_addr is
programmed in the HW with exception of BE3 VFs where the initial
MAC is programmed by parent PF. This is OK when MAC address is not
changed when an interfaces is down. In this case the requested MAC is
stored to netdev->dev_addr and later is stored into HW during opening.
But this is not done for all BE3 VFs so the NIC HW does not know
anything about this change and all traffic is filtered.
This is the case of bonding if fail_over_mac == 0 where the MACs of
the slaves are changed while they are down.
The be2net behavior is too restrictive because if a BE3 VF has
the FILTMGMT privilege then it is able to modify its MAC without
any restriction.
To solve the described problem the driver should take care about these
privileged BE3 VFs so the MAC is programmed during opening. And by
contrast unpriviled BE3 VFs should not be allowed to change its MAC
in any case.
Cc: Sathya Perla <sathya.perla@broadcom.com>
Cc: Ajit Khaparde <ajit.khaparde@broadcom.com>
Cc: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
Cc: Somnath Kotur <somnath.kotur@broadcom.com>
Signed-off-by: Ivan Vecera <cera@cera.cz>
---
drivers/net/ethernet/emulex/benet/be_main.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/emulex/benet/be_main.c b/drivers/net/ethernet/emulex/benet/be_main.c
index d606e20..1a7f8ad 100644
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -318,6 +318,13 @@ static int be_mac_addr_set(struct net_device *netdev, void *p)
if (ether_addr_equal(addr->sa_data, adapter->dev_mac))
return 0;
+ /* BE3 VFs without FILTMGMT privilege are not allowed to set its MAC
+ * address
+ */
+ if (BEx_chip(adapter) && be_virtfn(adapter) &&
+ !check_privilege(adapter, BE_PRIV_FILTMGMT))
+ return -EPERM;
+
/* if device is not running, copy MAC to netdev->dev_addr */
if (!netif_running(netdev))
goto done;
@@ -3766,8 +3773,9 @@ static int be_enable_if_filters(struct be_adapter *adapter)
if (status)
return status;
- /* For BE3 VFs, the PF programs the initial MAC address */
- if (!(BEx_chip(adapter) && be_virtfn(adapter))) {
+ /* Don't add MAC on BE3 VFs without FILTMGMT privilege */
+ if (!BEx_chip(adapter) || !be_virtfn(adapter) ||
+ check_privilege(adapter, BE_PRIV_FILTMGMT)) {
status = be_dev_mac_add(adapter, adapter->netdev->dev_addr);
if (status)
return status;
--
2.10.2
^ permalink raw reply related
* Re: [pull request][for-next] Mellanox mlx5 Reorganize core driver directory layout
From: Tom Herbert @ 2017-01-13 22:06 UTC (permalink / raw)
To: Leon Romanovsky
Cc: David Miller, Saeed Mahameed, dledford,
Linux Kernel Network Developers, linux-rdma
In-Reply-To: <20170113202932.GS20392@mtr-leonro.local>
On Fri, Jan 13, 2017 at 12:29 PM, Leon Romanovsky <leon@kernel.org> wrote:
> On Fri, Jan 13, 2017 at 12:14:07PM -0500, David Miller wrote:
>> From: Saeed Mahameed <saeedm@mellanox.com>
>> Date: Thu, 12 Jan 2017 19:22:34 +0200
>>
>> > This pull request includes one patch from Leon, this patch as described
>> > below will change the driver directory structure and layout for better,
>> > logical and modular driver files separation.
>> >
>> > This change is important to both rdma and net maintainers in order to
>> > have smoother management of driver patches for different mlx5 sub modules
>> > and smoother rdma-next vs. net-next features submissions.
>> >
>> > Please find more info below -in the tag commit message-,
>> > review and let us know if there's any problem.
>> >
>> > This change doesn't introduce any conflicts with the current mlx5
>> > fixes and cleanups posted on 2017-01-10 to net branch, and merge tests
>> > worked flawlessly with no issues.
>> >
>> > This is the last pull request meant for both rdma-next and net-next.
>> > Once pulled, this will be the base shared code for both trees.
>>
>> This is pretty crazy, it will make all bug fix backporting to -stable
>> a complete nightmare for myself, Doug, various distribution maintainers
>> and many other people who quietly have to maintain their own trees and
>> do backporting.
>
> Hi Dave,
>
> I understand your worries, but our case is similar to various other
> drivers, for example hfi1 which was in staging for years while
> supported in RedHat and moved from there to IB. The Chelsio drivers did
> similar reorg in 2016 (drivers/net/ethernet/chelsio/libcxgb) while their
> drivers were in the tree for long time before.
>
> Additionally, Doug doesn't need to maintain -stable queue and it is done
> by relevant submaintainers who are adding stable tags by themselves. In
> the IB case, the burden will continue to be on me and not on Doug.
>
Recently I had to backport the mlx5 driver from 4.9 to 4.6 in order to
get support for XDP. The biggest issue I faced was the lack of
modularity in the many driver features that are now supported. The
problem with backporting these new features is the spider web of
dependencies that they bring in from the rest of the kernel. I ended
up taking out en_rep, vxlan, en_tc, eswitch, and dcbnl. The result was
~340 patches which is still a lot but at least this was constrained to
patches in the mlx5 directories and are relevant to what we want to
do.
In lieu of restructuring the directories, I would much rather see more
config options so that we can build drivers that don't unnecessarily
complicate our lives with features we don't use. This is not just true
for Mellanox, but I would say it would be true of any driver that
someone is trying to deploy and maintain at large scale.
Btw, we did hit one issue in the backport. We started to get rx csum
faults (checksum complete value indicates TCP checksum is bad, but
host computation says checksum is good). I ran against 4.9 upstream
kernel and do see these, however don't see them in 4.10. I haven't
bisected yet. Is this a known issue?
Thanks,
Tom
>>
>> I really don't think you can justify this rearrangement based upon the
>> consequences and how much activity happens in this driver.
>>
>> You should have thought long and hard about the layout a long time ago
>> rather than after the driver has been in the tree for many years.
>>
>> Sorry.
^ permalink raw reply
* Re: [pull request][for-next] Mellanox mlx5 Reorganize core driver directory layout
From: Saeed Mahameed @ 2017-01-13 22:07 UTC (permalink / raw)
To: David Miller
Cc: Saeed Mahameed, Doug Ledford, Linux Netdev List, linux-rdma,
Leon Romanovsky
In-Reply-To: <20170113.121407.448230751444957957.davem@davemloft.net>
On Fri, Jan 13, 2017 at 7:14 PM, David Miller <davem@davemloft.net> wrote:
> From: Saeed Mahameed <saeedm@mellanox.com>
> Date: Thu, 12 Jan 2017 19:22:34 +0200
>
>> This pull request includes one patch from Leon, this patch as described
>> below will change the driver directory structure and layout for better,
>> logical and modular driver files separation.
>>
>> This change is important to both rdma and net maintainers in order to
>> have smoother management of driver patches for different mlx5 sub modules
>> and smoother rdma-next vs. net-next features submissions.
>>
>> Please find more info below -in the tag commit message-,
>> review and let us know if there's any problem.
>>
>> This change doesn't introduce any conflicts with the current mlx5
>> fixes and cleanups posted on 2017-01-10 to net branch, and merge tests
>> worked flawlessly with no issues.
>>
>> This is the last pull request meant for both rdma-next and net-next.
>> Once pulled, this will be the base shared code for both trees.
>
> This is pretty crazy, it will make all bug fix backporting to -stable
> a complete nightmare for myself, Doug, various distribution maintainers
> and many other people who quietly have to maintain their own trees and
> do backporting.
>
I hear you,
But please bear with me here, what if we queue this patch up to -stable ? and we
(Mellanox) and specifically our dedicated inbox team, will make sure
that this patch
will land on the various distributions and for those maintaining their
own trees.
This patch is really straight forward (rename files) and I already
tried to cherry-pick it
on older kernels, I only got a couple of conflicts on some of the
"#inlcude" lines we've
changed, and they are pretty straightforward to fix, we can even avoid
this if we decide to
not move mlx5 header files in this phase.
If this is possible then all trees will be aligned and it will be a
win win situation.
> I really don't think you can justify this rearrangement based upon the
> consequences and how much activity happens in this driver.
>
Right, but this is not the only justification, I can sum it up to that
we would like
to lay out the foundation for many years to come for a well designed
driver with a modular
sub modules break down and scalable infrastructure. We already plan to
submit more mlx5
independent sub modules - just like mlx5e (en_*) files and mlx5_ib
driver- so this was also
a reason for us to consider this re-engagement at this stage.
> You should have thought long and hard about the layout a long time ago
> rather than after the driver has been in the tree for many years.
>
I had this Idea for the separation before the mlx5 Ethernet
submission, but I wasn't the maintainer
back then, and i have been itching to submit such patch for long as
well, still i don't think
it is too late, We (Me and Leon) will keep maintaining this driver for
only god knows how many years to come,
and the mlx5 drivers are meant to serve at least 3-4 more future HW generations.
Long story short, We would like to re-arrange the driver in a way that
would serve us (the maintainers) and serve those
who are going do develop the future Stack features and the future HW
generations over the well designed (Hopefully)
mlx5 infrastructure.
Keeping it as it is today, will only make the situation worst in the
future and it will be really hard to avoid having a spaghetti code
in the mlx5 driver. All i want to point out here is that maintaining
such a flat subtree is also nightmare.
So i am only asking you to reconsider this change and give my -stable
suggestion a thought.
Thank you.
Saeed.
^ permalink raw reply
* Re: Commit 1fe8e0... (include more headers in if_tunnel.h) breaks my user-space build.
From: Stephen Hemminger @ 2017-01-13 22:08 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev, mikko.rapeli
In-Reply-To: <6c983e7e-dbb3-3542-ffed-95f4d2f3c5bc@candelatech.com>
On Fri, 13 Jan 2017 11:50:32 -0800
Ben Greear <greearb@candelatech.com> wrote:
> On 01/13/2017 11:41 AM, Stephen Hemminger wrote:
> > On Fri, 13 Jan 2017 11:12:32 -0800
> > Ben Greear <greearb@candelatech.com> wrote:
> >
> >> I am including netinet/ip.h, and also linux/if_tunnel.h, and the linux/ip.h conflicts with
> >> netinet/ip.h.
> >>
> >> Maybe my build environment is screwed up, but maybe also it would be better to
> >> just let the user include appropriate headers before including if_tunnel.h
> >> and revert this patch?
> >>
> >>
> >> include/uapi/linux/if_tunnel.h: include linux/if.h, linux/ip.h and linux/in6.h
> >>
> >> Fixes userspace compilation errors like:
> >>
> >> error: field ‘iph’ has incomplete type
> >> error: field ‘prefix’ has incomplete type
> >>
> >> Signed-off-by: Mikko Rapeli <mikko.rapeli@iki.fi>
> >> Signed-off-by: David S. Miller <davem@davemloft.net>
> >>
> >> Thanks,
> >> Ben
> >>
> >
> > What I ended up doing for iproute2 was including all headers used by the source
> > based on sanitized kernel headers. Basically
> > $ git grep '^#include <linux/' | \
> > awk -F: '{print $2}' | \
> > sed -e 's/^#include <//' -e 's/>.*$//' | \
> > sort -u >linux.headers
> > $ for f in $(cat linux.headers)
> > do cp ~/kernel/net-next/usr/include/$f include/$f
> > done
> >
> > You can't take only some of the headers, once you decide to diverge from glibc provided
> > headers, you got to take them all.
> >
>
> I do grab a copy of the linux kernel headers and compile against that, but netinet/ip.h is
> coming from the OS. Do you mean I should not include netinet/ip.h and instead use linux/ip.h?
I don't think you can mix netinet/ip.h and linux/ip.h, yes that is a mess.
^ 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