* Re: [PATCH net-next] drivers: net: cpsw: make cpsw_ale.c a module to allow re-use on Keystone
From: Tony Lindgren @ 2015-02-02 16:40 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Murali Karicheri, w-kwok2, davem, mugunthanvnm, prabhakar.csengg,
grygorii.strashko, lokeshvutla, mpa, lsorense, netdev,
linux-kernel
In-Reply-To: <1802322.NDR3d5ZRSA@wuerfel>
* Arnd Bergmann <arnd@arndb.de> [150129 15:51]:
> On Thursday 29 January 2015 18:15:51 Murali Karicheri wrote:
> > NetCP on Keystone has cpsw ale function similar to other TI SoCs
> > and this driver is re-used. To allow both ti cpsw and keystone netcp
> > to re-use the driver, convert the cpsw ale to a module and configure
> > it through Kconfig option CONFIG_TI_CPSW_ALE. Currently it is statically
> > linked to both TI CPSW and NetCP and this causes issues when the above
> > drivers are built as dynamic modules. This patch addresses this issue
> >
> > While at it, fix the Makefile and code to build both netcp_core and
> > netcp_ethss as dynamic modules. This is needed to support arm allmodconfig.
> > This also requires exporting of API calls provided by netcp_core so that
> > both the above can be dynamic modules.
> >
> > Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
> > ---
> > drivers/net/ethernet/ti/Kconfig | 19 +++++++++++++++++--
> > drivers/net/ethernet/ti/Makefile | 8 +++++---
> > drivers/net/ethernet/ti/cpsw_ale.c | 26 ++++++++++++++++++++++++--
> > drivers/net/ethernet/ti/netcp_core.c | 8 ++++++++
> > drivers/net/ethernet/ti/netcp_ethss.c | 5 +++++
> > 5 files changed, 59 insertions(+), 7 deletions(-)
>
> I was hoping there would be a way without exporting all those symbols, but
> I also couldn't come up with a better solution. I'm putting this into the
> randconfig build test for now, but I'm guessing it's fine.
Probably the best way in the long run is to add a single exported
function to cpsw-common.c I just added for the MAC address function.
Then all the cpsw like drivers can register with that instead of
having tons of custom exported functions.
But before doing that, we should have a clear idea what all can
be shared. Murali, maybe you can take a look at that?
Regards,
Tony
^ permalink raw reply
* [PATCHv1 net] xen-netback: stop the guest rx thread after a fatal error
From: David Vrabel @ 2015-02-02 16:57 UTC (permalink / raw)
To: netdev; +Cc: David Vrabel, xen-devel, Ian Campbell, Wei Liu
After commit e9d8b2c2968499c1f96563e6522c56958d5a1d0d (xen-netback:
disable rogue vif in kthread context), a fatal (protocol) error would
leave the guest Rx thread spinning, wasting CPU time. Commit
ecf08d2dbb96d5a4b4bcc53a39e8d29cc8fef02e (xen-netback: reintroduce
guest Rx stall detection) made this even worse by removing a
cond_resched() from this path.
Since a fatal error is non-recoverable, just allow the guest Rx thread
to exit. This requires taking additional refs to the task so the
thread exiting early is handled safely.
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Reported-by: Julien Grall <julien.grall@linaro.org>
Tested-by: Julien Grall <julien.grall@linaro.org>
---
drivers/net/xen-netback/interface.c | 2 ++
drivers/net/xen-netback/netback.c | 3 +--
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
index 9259a73..037f74f 100644
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -578,6 +578,7 @@ int xenvif_connect(struct xenvif_queue *queue, unsigned long tx_ring_ref,
goto err_rx_unbind;
}
queue->task = task;
+ get_task_struct(task);
task = kthread_create(xenvif_dealloc_kthread,
(void *)queue, "%s-dealloc", queue->name);
@@ -634,6 +635,7 @@ void xenvif_disconnect(struct xenvif *vif)
if (queue->task) {
kthread_stop(queue->task);
+ put_task_struct(queue->task);
queue->task = NULL;
}
diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
index 908e65e..c8ce701 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -2109,8 +2109,7 @@ int xenvif_kthread_guest_rx(void *data)
*/
if (unlikely(vif->disabled && queue->id == 0)) {
xenvif_carrier_off(vif);
- xenvif_rx_queue_purge(queue);
- continue;
+ break;
}
if (!skb_queue_empty(&queue->rx_queue))
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCHv1 net] xen-netback: stop the guest rx thread after a fatal error
From: Wei Liu @ 2015-02-02 17:00 UTC (permalink / raw)
To: David Vrabel; +Cc: netdev, xen-devel, Ian Campbell, Wei Liu
In-Reply-To: <1422896271-26551-1-git-send-email-david.vrabel@citrix.com>
On Mon, Feb 02, 2015 at 04:57:51PM +0000, David Vrabel wrote:
> After commit e9d8b2c2968499c1f96563e6522c56958d5a1d0d (xen-netback:
> disable rogue vif in kthread context), a fatal (protocol) error would
> leave the guest Rx thread spinning, wasting CPU time. Commit
> ecf08d2dbb96d5a4b4bcc53a39e8d29cc8fef02e (xen-netback: reintroduce
> guest Rx stall detection) made this even worse by removing a
> cond_resched() from this path.
>
> Since a fatal error is non-recoverable, just allow the guest Rx thread
> to exit. This requires taking additional refs to the task so the
> thread exiting early is handled safely.
>
> Signed-off-by: David Vrabel <david.vrabel@citrix.com>
> Reported-by: Julien Grall <julien.grall@linaro.org>
> Tested-by: Julien Grall <julien.grall@linaro.org>
Acked-by: Wei Liu <wei.liu2@citrix.com>
> ---
> drivers/net/xen-netback/interface.c | 2 ++
> drivers/net/xen-netback/netback.c | 3 +--
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/xen-netback/interface.c b/drivers/net/xen-netback/interface.c
> index 9259a73..037f74f 100644
> --- a/drivers/net/xen-netback/interface.c
> +++ b/drivers/net/xen-netback/interface.c
> @@ -578,6 +578,7 @@ int xenvif_connect(struct xenvif_queue *queue, unsigned long tx_ring_ref,
> goto err_rx_unbind;
> }
> queue->task = task;
> + get_task_struct(task);
>
> task = kthread_create(xenvif_dealloc_kthread,
> (void *)queue, "%s-dealloc", queue->name);
> @@ -634,6 +635,7 @@ void xenvif_disconnect(struct xenvif *vif)
>
> if (queue->task) {
> kthread_stop(queue->task);
> + put_task_struct(queue->task);
> queue->task = NULL;
> }
>
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-netback/netback.c
> index 908e65e..c8ce701 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -2109,8 +2109,7 @@ int xenvif_kthread_guest_rx(void *data)
> */
> if (unlikely(vif->disabled && queue->id == 0)) {
> xenvif_carrier_off(vif);
> - xenvif_rx_queue_purge(queue);
> - continue;
> + break;
> }
>
> if (!skb_queue_empty(&queue->rx_queue))
> --
> 1.7.10.4
^ permalink raw reply
* [PATCH] net: fs_enet: Implement NETIF_F_SG feature
From: Christophe Leroy @ 2015-02-02 17:06 UTC (permalink / raw)
To: Pantelis Antoniou, Vitaly Bordug, davem
Cc: linux-kernel, linuxppc-dev, netdev
Freescale ethernet controllers have the capability to re-assemble fragmented
data into a single ethernet frame. This patch uses this capability and
implements NETIP_F_SG feature into the fs_enet ethernet driver.
On a MPC885, I get 53% performance improvement on a ftp transfer of a 15Mb file:
* Without the patch : 2,8 Mbps
* With the patch : 4,3 Mbps
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
.../net/ethernet/freescale/fs_enet/fs_enet-main.c | 95 +++++++++++++++-------
drivers/net/ethernet/freescale/fs_enet/fs_enet.h | 1 +
2 files changed, 66 insertions(+), 30 deletions(-)
diff --git a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
index 9e2bcb8..a176287 100644
--- a/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
+++ b/drivers/net/ethernet/freescale/fs_enet/fs_enet-main.c
@@ -278,14 +278,20 @@ static int fs_enet_tx_napi(struct napi_struct *napi, int budget)
fep->stats.collisions++;
/* unmap */
- dma_unmap_single(fep->dev, CBDR_BUFADDR(bdp),
- skb->len, DMA_TO_DEVICE);
+ if (fep->mapped_as_page[dirtyidx])
+ dma_unmap_page(fep->dev, CBDR_BUFADDR(bdp),
+ CBDR_DATLEN(bdp), DMA_TO_DEVICE);
+ else
+ dma_unmap_single(fep->dev, CBDR_BUFADDR(bdp),
+ CBDR_DATLEN(bdp), DMA_TO_DEVICE);
/*
* Free the sk buffer associated with this last transmit.
*/
- dev_kfree_skb(skb);
- fep->tx_skbuff[dirtyidx] = NULL;
+ if (skb) {
+ dev_kfree_skb(skb);
+ fep->tx_skbuff[dirtyidx] = NULL;
+ }
/*
* Update pointer to next buffer descriptor to be transmitted.
@@ -299,7 +305,7 @@ static int fs_enet_tx_napi(struct napi_struct *napi, int budget)
* Since we have freed up a buffer, the ring is no longer
* full.
*/
- if (!fep->tx_free++)
+ if (++fep->tx_free >= MAX_SKB_FRAGS)
do_wake = 1;
has_tx_work = 1;
}
@@ -509,6 +515,9 @@ static int fs_enet_start_xmit(struct sk_buff *skb, struct net_device *dev)
cbd_t __iomem *bdp;
int curidx;
u16 sc;
+ int nr_frags = skb_shinfo(skb)->nr_frags;
+ skb_frag_t *frag;
+ int len;
#ifdef CONFIG_FS_ENET_MPC5121_FEC
if (((unsigned long)skb->data) & 0x3) {
@@ -530,7 +539,7 @@ static int fs_enet_start_xmit(struct sk_buff *skb, struct net_device *dev)
*/
bdp = fep->cur_tx;
- if (!fep->tx_free || (CBDR_SC(bdp) & BD_ENET_TX_READY)) {
+ if (fep->tx_free <= nr_frags || (CBDR_SC(bdp) & BD_ENET_TX_READY)) {
netif_stop_queue(dev);
spin_unlock(&fep->tx_lock);
@@ -543,35 +552,42 @@ static int fs_enet_start_xmit(struct sk_buff *skb, struct net_device *dev)
}
curidx = bdp - fep->tx_bd_base;
- /*
- * Clear all of the status flags.
- */
- CBDC_SC(bdp, BD_ENET_TX_STATS);
-
- /*
- * Save skb pointer.
- */
- fep->tx_skbuff[curidx] = skb;
-
- fep->stats.tx_bytes += skb->len;
+ len = skb->len;
+ fep->stats.tx_bytes += len;
+ if (nr_frags)
+ len -= skb->data_len;
+ fep->tx_free -= nr_frags + 1;
/*
* Push the data cache so the CPM does not get stale memory data.
*/
CBDW_BUFADDR(bdp, dma_map_single(fep->dev,
- skb->data, skb->len, DMA_TO_DEVICE));
- CBDW_DATLEN(bdp, skb->len);
+ skb->data, len, DMA_TO_DEVICE));
+ CBDW_DATLEN(bdp, len);
+
+ fep->mapped_as_page[curidx] = 0;
+ frag = skb_shinfo(skb)->frags;
+ while (nr_frags) {
+ CBDC_SC(bdp,
+ BD_ENET_TX_STATS | BD_ENET_TX_LAST | BD_ENET_TX_TC);
+ CBDS_SC(bdp, BD_ENET_TX_READY);
+
+ if ((CBDR_SC(bdp) & BD_ENET_TX_WRAP) == 0)
+ bdp++, curidx++;
+ else
+ bdp = fep->tx_bd_base, curidx = 0;
- /*
- * If this was the last BD in the ring, start at the beginning again.
- */
- if ((CBDR_SC(bdp) & BD_ENET_TX_WRAP) == 0)
- fep->cur_tx++;
- else
- fep->cur_tx = fep->tx_bd_base;
+ len = skb_frag_size(frag);
+ CBDW_BUFADDR(bdp, skb_frag_dma_map(fep->dev, frag, 0, len,
+ DMA_TO_DEVICE));
+ CBDW_DATLEN(bdp, len);
- if (!--fep->tx_free)
- netif_stop_queue(dev);
+ fep->tx_skbuff[curidx] = NULL;
+ fep->mapped_as_page[curidx] = 1;
+
+ frag++;
+ nr_frags--;
+ }
/* Trigger transmission start */
sc = BD_ENET_TX_READY | BD_ENET_TX_INTR |
@@ -582,8 +598,22 @@ static int fs_enet_start_xmit(struct sk_buff *skb, struct net_device *dev)
* yay for hw reuse :) */
if (skb->len <= 60)
sc |= BD_ENET_TX_PAD;
+ CBDC_SC(bdp, BD_ENET_TX_STATS);
CBDS_SC(bdp, sc);
+ /* Save skb pointer. */
+ fep->tx_skbuff[curidx] = skb;
+
+ /* If this was the last BD in the ring, start at the beginning again. */
+ if ((CBDR_SC(bdp) & BD_ENET_TX_WRAP) == 0)
+ bdp++;
+ else
+ bdp = fep->tx_bd_base;
+ fep->cur_tx = bdp;
+
+ if (fep->tx_free < MAX_SKB_FRAGS)
+ netif_stop_queue(dev);
+
skb_tx_timestamp(skb);
(*fep->ops->tx_kickstart)(dev);
@@ -917,7 +947,7 @@ static int fs_enet_probe(struct platform_device *ofdev)
}
fpi->rx_ring = 32;
- fpi->tx_ring = 32;
+ fpi->tx_ring = 64;
fpi->rx_copybreak = 240;
fpi->napi_weight = 17;
fpi->phy_node = of_parse_phandle(ofdev->dev.of_node, "phy-handle", 0);
@@ -955,7 +985,8 @@ static int fs_enet_probe(struct platform_device *ofdev)
privsize = sizeof(*fep) +
sizeof(struct sk_buff **) *
- (fpi->rx_ring + fpi->tx_ring);
+ (fpi->rx_ring + fpi->tx_ring) +
+ sizeof(char) * fpi->tx_ring;
ndev = alloc_etherdev(privsize);
if (!ndev) {
@@ -978,6 +1009,8 @@ static int fs_enet_probe(struct platform_device *ofdev)
fep->rx_skbuff = (struct sk_buff **)&fep[1];
fep->tx_skbuff = fep->rx_skbuff + fpi->rx_ring;
+ fep->mapped_as_page = (char *)(fep->rx_skbuff + fpi->rx_ring +
+ fpi->tx_ring);
spin_lock_init(&fep->lock);
spin_lock_init(&fep->tx_lock);
@@ -1007,6 +1040,8 @@ static int fs_enet_probe(struct platform_device *ofdev)
netif_carrier_off(ndev);
+ ndev->features |= NETIF_F_SG;
+
ret = register_netdev(ndev);
if (ret)
goto out_free_bd;
diff --git a/drivers/net/ethernet/freescale/fs_enet/fs_enet.h b/drivers/net/ethernet/freescale/fs_enet/fs_enet.h
index 3a4b49e..f184d8f 100644
--- a/drivers/net/ethernet/freescale/fs_enet/fs_enet.h
+++ b/drivers/net/ethernet/freescale/fs_enet/fs_enet.h
@@ -134,6 +134,7 @@ struct fs_enet_private {
void __iomem *ring_base;
struct sk_buff **rx_skbuff;
struct sk_buff **tx_skbuff;
+ char *mapped_as_page;
cbd_t __iomem *rx_bd_base; /* Address of Rx and Tx buffers. */
cbd_t __iomem *tx_bd_base;
cbd_t __iomem *dirty_tx; /* ring entries to be free()ed. */
--
2.1.0
^ permalink raw reply related
* [PATCH net-next] bridge: Let bridge not age 'externally' learnt FDB entries, they are removed when 'external' entity notifies the aging
From: Siva Mannem @ 2015-02-02 17:21 UTC (permalink / raw)
To: netdev; +Cc: Siva Mannem
When 'learned_sync' flag is turned on, the offloaded switch
port syncs learned MAC addresses to bridge's FDB via switchdev notifier
(NETDEV_SWITCH_FDB_ADD). Currently, FDB entries learnt via this mechanism are
wrongly being deleted by bridge aging logic. This patch ensures that FDB
entries synced from offloaded switch ports are not deleted by bridging logic.
Such entries can only be deleted via switchdev notifier
(NETDEV_SWITCH_FDB_DEL).
Signed-off-by: Siva Mannem <siva.mannem.lnx@gmail.com>
---
net/bridge/br_fdb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
index 08bf04b..6eb94b5 100644
--- a/net/bridge/br_fdb.c
+++ b/net/bridge/br_fdb.c
@@ -280,7 +280,7 @@ void br_fdb_cleanup(unsigned long _data)
hlist_for_each_entry_safe(f, n, &br->hash[i], hlist) {
unsigned long this_timer;
- if (f->is_static)
+ if (f->is_static || f->added_by_external_learn)
continue;
this_timer = f->updated + delay;
if (time_before_eq(this_timer, jiffies))
--
2.1.0
^ permalink raw reply related
* Re: [PATCH] net: ipv6: Make address flushing on ifdown optional - v2
From: Brian Haley @ 2015-02-02 17:38 UTC (permalink / raw)
To: David Ahern, netdev; +Cc: Hannes Frederic Sowa
In-Reply-To: <1422504065-17445-1-git-send-email-dsahern@gmail.com>
On 01/28/2015 11:01 PM, David Ahern wrote:
> Currently, all ipv6 addresses are flushed when the interface is configured
> down, even static address:
>
...
> diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
> index 2805062c013f..b91b7c8be023 100644
> --- a/include/linux/ipv6.h
> +++ b/include/linux/ipv6.h
> @@ -53,6 +53,7 @@ struct ipv6_devconf {
> __s32 ndisc_notify;
> __s32 suppress_frag_ndisc;
> __s32 accept_ra_mtu;
> + __s32 flush_addr_on_down;
> void *sysctl;
> };
...
> diff --git a/include/uapi/linux/ipv6.h b/include/uapi/linux/ipv6.h
> index 437a6a4b125a..ed10d4ba8340 100644
> --- a/include/uapi/linux/ipv6.h
> +++ b/include/uapi/linux/ipv6.h
> @@ -170,6 +170,7 @@ enum {
> DEVCONF_ACCEPT_RA_FROM_LOCAL,
> DEVCONF_USE_OPTIMISTIC,
> DEVCONF_ACCEPT_RA_MTU,
> + DEVCONF_FLUSH_ON_DOWN,
nit: DEVCONF_FLUSH_ADDR_ON_DOWN to match the name added to ipv6_devconf.
-Brian
^ permalink raw reply
* RE: [PATCH net-next 0/4] enic: improve rq buff allocation and reduce dma mapping
From: Govindarajulu Varadarajan @ 2015-02-02 17:49 UTC (permalink / raw)
To: David Laight
Cc: 'Govindarajulu Varadarajan', davem@davemloft.net,
netdev@vger.kernel.org, ssujith@cisco.com, benve@cisco.com,
edumazet@google.com, ben@decadent.org.uk
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1CAD8FD1@AcuExch.aculab.com>
On Mon, 2 Feb 2015, David Laight wrote:
> Two questions:
> 1) How are you handling the skb's true_size ?
skb->true_size is set to ksize(data) for data allocated using alloc_page and
kmalloc. For frags we set it to size of frag. Check the function build_skb()
> 2) Memory fragmentation could easily make the allocation of 32k fail.
>
With huge memory these days order-3 allocation failure is quite rare. In my
testing on system with 8G memory I have never encountered order-3 failure.
This is probably why __netdev_alloc_frag tries order-3 page allocation first.
If order-3 page allocation fails, we drop to minimum order required for the
given size.
^ permalink raw reply
* Re: AF_NETDEV - device specific sockets
From: John Fastabend @ 2015-02-02 18:04 UTC (permalink / raw)
To: Zayats, Michael; +Cc: netdev@vger.kernel.org, dborkman
In-Reply-To: <FC8E8D0ECC753F45808079B18C3203FE1CCAF4@G4W3293.americas.hpqcorp.net>
On 01/31/2015 09:04 PM, Zayats, Michael wrote:
> More specific example would be when NIC performs certain fast path processing,
> while punting to the CPU for a slow path.
> Slow path would be interested to know the punt reason.
>
> Another example would be if specific NIC strips S-tag in QinQ case and would like to communicate the stripped
> Tag to the client.
>
Right, maybe we need some sort of TLV scheme to pass up the relevant
info. I'm not sure we want to necessarily bury it in the driver though.
Perhaps passing auxdata in a TLV format is worth considering.
Just curious do you have NICs that are stripping or inserting more then
a single tag?
For tagging my current scheme is to strip outer tags using this
experimental Flow API
http://www.spinics.net/lists/netdev/msg313071.html
and then only report the inner tag to the stack. At the moment I haven't
found any use cases this is not sufficient.
> There might be many types of custom functionality, agreed between the NIC and the clients,
> which is not generic or not practical enough for inclusion in the kernel.
>
> That's why I am looking for a generic, socket like mechanism of device<->client, packet + metadata communication,
> which wouldn't require core kernel modification.
hmm the question is how do the NIC and client "agree" on the
format of the data and its meaning? If you follow the thread
above and also our af_packet direct DMA work we are struggling
with similar questions,
http://www.spinics.net/lists/netdev/msg311862.html
I think we need some way to "describe" the meta-data or we
need to build some kernel/uapi standard that defines them.
.John
>
> Thanks,
>
> Michael
>
>
>
>
>
> -----Original Message-----
> From: John Fastabend [mailto:john.fastabend@gmail.com]
> Sent: Saturday, January 31, 2015 8:41 PM
> To: Zayats, Michael
> Cc: netdev@vger.kernel.org
> Subject: Re: AF_NETDEV - device specific sockets
>
> On 01/31/2015 08:20 PM, Zayats, Michael wrote:
>> Hi,
>>
>> I am looking for a generic mechanism that would allow network device
>> drivers to provide socket interface to user and kernel space clients.
>>
>> Such an interface might be used to provide access to important
>> sub-streams of packets, alongside with device specific packet
>> metadata, provided through msg_control fields of recv/sendmsg.
>>
>> RX Metadata might include device specific information, such as queuing
>> priorities applied, potential destination interface in case of
>> switching hardware etc.
>>
>> On the transmission, metadata might be used to indicate hardware
>> specific required optimizations, as well as any other transformation
>> or accounting required on the packet.
>>
>> AF_PACKET based mechanism doesn't allow metadata to be exchanged
>> between the client and the device driver. Extending it would require
>> extending of sk_buff and potentially additional per packet operations.
>> Generic Netlink is not intended to pass packets.
>>
>> As I am trying to validate generic applicability of such a mechanism,
>> I see that TUN driver is providing custom socket interface, in order
>> to deal with user information through msg_control. Only usable inside
>> the kernel, through custom interface.
>
>> Proposed interface
>> ------------------
>> Kernel side:
>> (struct proto *) should be added to struct net_device.
>> Device driver that is interested to support socket interface would populate the pointer.
>>
>
>> User space: After creating AF_NETDEV socket, the only successful
>> operation would be setting SO_BINDTODEVICE option. Once set, all
>> socket operations would be implemented by calling functions, that are
>> registered at struct proto on the appropriate net_device.
>>
>> What do you think?
>> Would you see a better approach?
>> Some other mechanism that already exists for such a purpose?
>
> It might help to come up with specific examples but an alternate proposal would be to use skb->priority field and then mqprio to steer the traffic to a specific queue and then bind attributes to the queue.
>
> For example the NIC offloaded QOS can be mapped on to queues and then sockets mapped to the queues.
>
> Another example would be to forward all traffic from one queue to a virtual fuction in SR-IOV use case. We don't have an interface to do this but I have been working on an API that could be used for this.
>
> In this case you don't need to modify AF_PACKET interface but configure the device correctly. If you need per-packet control you could use 'tc' or 'nftables' to do the steering.
>
> .John
>
--
John Fastabend Intel Corporation
^ permalink raw reply
* Re: [PATCH net-next v2 0/6] net: Add STT support.
From: Pravin Shelar @ 2015-02-02 18:44 UTC (permalink / raw)
To: Andy Gospodarek; +Cc: Tom Herbert, Alexander Duyck, David Miller, netdev
In-Reply-To: <20150130184446.GF13164@gospo.home.greyhouse.net>
On Fri, Jan 30, 2015 at 10:44 AM, Andy Gospodarek
<gospo@cumulusnetworks.com> wrote:
> On Thu, Jan 29, 2015 at 09:03:14PM -0800, Pravin Shelar wrote:
>> On Thu, Jan 29, 2015 at 8:17 PM, Tom Herbert <therbert@google.com> wrote:
>> > On Thu, Jan 29, 2015 at 8:04 PM, Pravin Shelar <pshelar@nicira.com> wrote:
>> >> On Thu, Jan 29, 2015 at 7:46 PM, Alexander Duyck
>> >> <alexander.duyck@gmail.com> wrote:
>> >>> On 01/29/2015 03:29 PM, Pravin B Shelar wrote:
>> >>>> Following patch series adds support for Stateless Transport
>> >>>> Tunneling protocol.
>> >>>> STT uses TCP segmentation offload available in most of NIC. On
>> >>>> packet xmit STT driver appends STT header along with TCP header
>> >>>> to the packet. For GSO packet GSO parameters are set according
>> >>>> to tunnel configuration and packet is handed over to networking
>> >>>> stack. This allows use of segmentation offload available in NICs
>> >>>>
>> >>>> The protocol is documented at
>> >>>> http://www.ietf.org/archive/id/draft-davie-stt-06.txt
>> >>>>
>> >>>> I will send out OVS userspace patch on ovs-dev mailing list.
>> >>>>
>> >>>> Following are test results. All tests are done on net-next with
>> >>>> STT and VXLAN kernel device without OVS.
>> >>>>
>> >>>> Single Netperf session:
>> >>>> =======================
>> >>>> VXLAN:
>> >>>> CPU utilization
>> >>>> - Send local: 1.26
>> >>>> - Recv remote: 8.62
>> >>>> Throughput: 4.9 Gbit/sec
>> >>>> STT:
>> >>>> CPU utilization
>> >>>> - Send local: 1.01
>> >>>> - Recv remote: 1.8
>> >>>> Throughput: 9.45 Gbit/sec
>> >>>>
>> >>>> Five Netperf sessions:
>> >>>> ======================
>> >>>> VXLAN:
>> >>>> CPU utilization
>> >>>> - Send local: 9.7
>> >>>> - Recv remote: 70 (varies from 60 to 80)
>> >>>> Throughput: 9.05 Gbit/sec
>> >>>> STT:
>> >>>> CPU utilization
>> >>>> - Send local: 5.85
>> >>>> - Recv remote: 14
>> >>>> Throughput: 9.47 Gbit/sec
>> >>>>
>> >>>
>> >>> What does the small packet or non-TCP performance look like for STT vs
>> >>> VXLAN? My concern is that STT looks like it is a one trick pony since
>> >>> all your numbers show is TCP TSO performance, and based on some of the
>> >>> comments in your patches it seems like other protocols such as UDP are
>> >>> going to suffer pretty badly due to things like the linearization overhead.
>> >>>
>> >>
>> >> Current implementation is targeted for TCP workloads thats why I
>> >> posted numbers with TCP, once UDP is optimized we can discuss UDP
>> >> numbers. I am pretty sure the STT code can be optimized further
>> >> specially for protocols other than TCP.
>> >> --
>> > There are many TCP workloads that use small packets, it is critical to
>> > test for these also. E.g. "super_netperf 200 -H <addr> -l 120 -t
>> > TCP_RR -- -r 1,1"
>> >
>> I have not tried it on STT device, I will collect those numbers.
>>
>> > Please provide the *exact* commands that you are using to configure
>> > stt for optimal performance.
>> >
>> To create STT tunnel device.
>> `ip link add stt1 type stt key 1 remote 1.1.2.128`
>>
>> No other configuration is needed.
>
> Thanks for posting some performance numbers with your patch. I also
> don't want to 'pile on' with additional complaints, but I do have one
> request.
>
> Can you share any specs (including number of cores and NIC hardware
> used) for the systems that gave you the above results? If you do not
> want to endorse a particular NIC that is fine -- I'm mostly curious how
> many cores were used and if UDP and TCP RSS were both being used in this
> configuration.
>
I used 16 core (Sandy bridge) machine with intel 10G NIC. I enabled
both UDP and TCP RSS for all tests.
^ permalink raw reply
* Re: [PATCH net-next v2 0/6] net: Add STT support.
From: Pravin Shelar @ 2015-02-02 18:44 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20150131.174037.1176748996497876060.davem@davemloft.net>
On Sat, Jan 31, 2015 at 5:40 PM, David Miller <davem@davemloft.net> wrote:
> From: Pravin B Shelar <pshelar@nicira.com>
> Date: Thu, 29 Jan 2015 15:29:16 -0800
>
>> Following patch series adds support for Stateless Transport
>> Tunneling protocol.
>> STT uses TCP segmentation offload available in most of NIC. On
>> packet xmit STT driver appends STT header along with TCP header
>> to the packet. For GSO packet GSO parameters are set according
>> to tunnel configuration and packet is handed over to networking
>> stack. This allows use of segmentation offload available in NICs
>
> I don't like this at all.
>
> Routers _absolutely_ depend upon the ability to make TCP flows back
> off by dropping packets in various ways (tail drop, RED random drops,
> etc.). STT violates this completely.
>
> It's _NOT_ TCP, you can't put lipstick on a pig and pretend it's not a
> pig. You need to use something that indicates it's flow properties,
> a datagram protocol. Either via an existing one or by creating a new
> one.
>
> I know you want to do this mass TCP behavioral violation because of
> TSO. But that's too bad. The ends do not justify the means.
>
> I also don't buy the argument that "people can put arbitrary changes
> into their kernel to do stuff like that".
>
> They can't do it to the stack I'm willing to maintain, and that's what
> matters for %99 of systems out there.
ok, I will drop patch series.
^ permalink raw reply
* Re: Throughput regression with `tcp: refine TSO autosizing`
From: Eric Dumazet @ 2015-02-02 18:52 UTC (permalink / raw)
To: Michal Kazior; +Cc: linux-wireless, Network Development, eyalpe
In-Reply-To: <CA+BoTQkV+mOZfe_Niz5101sMQeaV6muKCsShptjGQ1AgOHqqoQ@mail.gmail.com>
On Mon, 2015-02-02 at 11:27 +0100, Michal Kazior wrote:
> While testing I've had my internal GRO patch for ath10k and no stretch
> ack patches.
Thanks for the data, I took a look at it.
I am afraid this GRO patch might be the problem.
It seems to break ACK clocking badly (linux stack has a somewhat buggy
tcp_tso_should_defer(), which relies on ACK being received smoothly, as
no timer is setup to split the TSO packet.)
I am seeing huge delays on ACK packets and bursts like that :
05:01:53.413038 IP 192.168.1.2.5001 > 192.168.1.3.49669: Flags [.], ack 76745, win 4435, options [nop,nop,TS val 4294758508 ecr 4294757300], length 0
05:01:53.413407 IP 192.168.1.2.5001 > 192.168.1.3.49669: Flags [.], ack 79641, win 4435, options [nop,nop,TS val 4294758508 ecr 4294757301], length 0
05:01:53.413969 IP 192.168.1.2.5001 > 192.168.1.3.49669: Flags [.], ack 92673, win 4435, options [nop,nop,TS val 4294758510 ecr 4294757302], length 0
05:01:53.413990 IP 192.168.1.2.5001 > 192.168.1.3.49669: Flags [.], ack 97017, win 4435, options [nop,nop,TS val 4294758510 ecr 4294757302], length 0
05:01:53.414011 IP 192.168.1.2.5001 > 192.168.1.3.49669: Flags [.], ack 110049, win 4435, options [nop,nop,TS val 4294758510 ecr 4294757302], length 0
...
05:01:53.422663 IP 192.168.1.2.5001 > 192.168.1.3.49669: Flags [.], ack 189689, win 4435, options [nop,nop,TS val 4294758519 ecr 4294757310], length 0
05:01:53.424354 IP 192.168.1.2.5001 > 192.168.1.3.49669: Flags [.], ack 198377, win 4435, options [nop,nop,TS val 4294758520 ecr 4294757311], length 0
05:01:53.424400 IP 192.168.1.2.5001 > 192.168.1.3.49669: Flags [.], ack 202721, win 4435, options [nop,nop,TS val 4294758520 ecr 4294757313], length 0
05:01:53.424409 IP 192.168.1.2.5001 > 192.168.1.3.49669: Flags [.], ack 205617, win 4435, options [nop,nop,TS val 4294758520 ecr 4294757313], length 0
...
05:01:53.450248 IP 192.168.1.2.5001 > 192.168.1.3.49669: Flags [.], ack 419921, win 4435, options [nop,nop,TS val 4294758547 ecr 4294757337], length 0
05:01:53.450266 IP 192.168.1.2.5001 > 192.168.1.3.49669: Flags [.], ack 427161, win 4435, options [nop,nop,TS val 4294758547 ecr 4294757340], length 0
05:01:53.450289 IP 192.168.1.2.5001 > 192.168.1.3.49669: Flags [.], ack 431505, win 4435, options [nop,nop,TS val 4294758547 ecr 4294757340], length 0
Could you make again your experiments using upstream kernel (David
Miller net tree) ?
You also could post the GRO patch so that we can comment on it.
Thanks
^ permalink raw reply
* [PATCH net-next 1/2] pkt_sched: fq: avoid artificial bursts for clocked flows
From: Kenneth Klette Jonassen @ 2015-02-02 18:59 UTC (permalink / raw)
To: netdev; +Cc: Kenneth Klette Jonassen
Current pacing behavior always throttle flows for a time equal to one full
quantum, starting at the instance in time when a flow depletes its credit.
This is optimal for burst sizes that are a multiple of the chosen quantum.
For flows with many small and evenly clocked packets, the depletion and
refilling of credits cause packets to queue and transmit in bursts, even
when their clocked rate is below the pacing rate. With TCP ACKs, this
artificial queueing induces significant noise to RTTs, e.g. up to 2.07 ms
for rtt 20 ms, cwnd 10 and quantum 3028.
Packetdrill script to illustrate bursts:
0.000 socket(..., SOCK_DGRAM, IPPROTO_UDP) = 3
0.000 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
0.000 bind(3, ..., ...) = 0
0.000 connect(3, ..., ...) = 0
// SO_MAX_PACING_RATE: 2500 Bps, 100 ms per quantum, 20 ms per 50B packet.
0.000 setsockopt(3, SOL_SOCKET, 47, [2500], 4) = 0
0.000 `tc qdisc add dev tun0 root fq initial_quantum 250 quantum 250`
// Use 200 credits: send four perfectly spaced 50 byte packets.
0.000 write(3, ..., 22) = 22
0.000 > udp (22)
0.020 write(3, ..., 22) = 22
0.020 > udp (22)
0.040 write(3, ..., 22) = 22
0.040 > udp (22)
0.060 write(3, ..., 22) = 22
0.060 > udp (22)
// Send five perfectly spaced packets. The first credits are depleted at
// 1.000, and the remaining four packets are sent in a burst at 1.100.
// Packets are sent at their intended times when this patch is applied.
1.000 write(3, ..., 22) = 22
1.000 > udp (22)
1.020 write(3, ..., 22) = 22
1.040 write(3, ..., 22) = 22
1.060 write(3, ..., 22) = 22
1.080 write(3, ..., 22) = 22
1.100 > udp (22)
1.100 > udp (22)
1.100 > udp (22)
1.100 > udp (22)
Keep track of when a flows credit was last filled, and use this to
approximate a credit refill for each quantum of time that passes.
Increases memory footprint from 104 to 112 bytes per flow.
Signed-off-by: Kenneth Klette Jonassen <kennetkl@ifi.uio.no>
---
net/sched/sch_fq.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/net/sched/sch_fq.c b/net/sched/sch_fq.c
index 2a50f5c..6f0c45e 100644
--- a/net/sched/sch_fq.c
+++ b/net/sched/sch_fq.c
@@ -71,6 +71,7 @@ struct fq_flow {
struct rb_node rate_node; /* anchor in q->delayed tree */
u64 time_next_packet;
+ u64 time_credit_filled;
};
struct fq_flow_head {
@@ -250,6 +251,7 @@ static struct fq_flow *fq_classify(struct sk_buff *skb, struct fq_sched_data *q)
if (unlikely(skb->sk &&
f->socket_hash != sk->sk_hash)) {
f->credit = q->initial_quantum;
+ f->time_credit_filled = ktime_get_ns();
f->socket_hash = sk->sk_hash;
f->time_next_packet = 0ULL;
}
@@ -271,6 +273,7 @@ static struct fq_flow *fq_classify(struct sk_buff *skb, struct fq_sched_data *q)
if (skb->sk)
f->socket_hash = sk->sk_hash;
f->credit = q->initial_quantum;
+ f->time_credit_filled = ktime_get_ns();
rb_link_node(&f->fq_node, parent, p);
rb_insert_color(&f->fq_node, root);
@@ -374,8 +377,10 @@ static int fq_enqueue(struct sk_buff *skb, struct Qdisc *sch)
qdisc_qstats_backlog_inc(sch, skb);
if (fq_flow_is_detached(f)) {
fq_flow_add_tail(&q->new_flows, f);
- if (time_after(jiffies, f->age + q->flow_refill_delay))
+ if (time_after(jiffies, f->age + q->flow_refill_delay)) {
f->credit = max_t(u32, f->credit, q->quantum);
+ f->time_credit_filled = ktime_get_ns();
+ }
q->inactive_flows--;
}
@@ -440,6 +445,7 @@ begin:
if (f->credit <= 0) {
f->credit += q->quantum;
+ f->time_credit_filled = max(now, f->time_next_packet);
head->first = f->next;
fq_flow_add_tail(&q->old_flows, f);
goto begin;
@@ -489,7 +495,10 @@ begin:
q->stat_pkts_too_long++;
}
- f->time_next_packet = now + len;
+ /* If now < time_next_packet, throttles flow for a time equal
+ * to one quantum (len) after current credits were filled.
+ */
+ f->time_next_packet = f->time_credit_filled + len;
}
out:
qdisc_bstats_update(sch, skb);
--
1.9.1
^ permalink raw reply related
* [PATCH net-next 2/2] pkt_sched: fq: remove redundant flow credit refill
From: Kenneth Klette Jonassen @ 2015-02-02 18:59 UTC (permalink / raw)
To: netdev; +Cc: Kenneth Klette Jonassen
In-Reply-To: <1422903556-30393-1-git-send-email-kennetkl@ifi.uio.no>
Current behavior explicitly refills flow credit after idle. But following
the first patch in this series, regular refill no longer throttles a flow
if idle_time >= quantum_time.
Remove redundant refill, and warn possible users of the refill delay knob.
Updates f52ed89971ad ("pkt_sched: fq: fix pacing for small frames").
Inspired by 65c5189a2b57 ("pkt_sched: fq: warn users using defrate").
Signed-off-by: Kenneth Klette Jonassen <kennetkl@ifi.uio.no>
---
include/uapi/linux/pkt_sched.h | 2 +-
net/sched/sch_fq.c | 20 ++++++--------------
2 files changed, 7 insertions(+), 15 deletions(-)
diff --git a/include/uapi/linux/pkt_sched.h b/include/uapi/linux/pkt_sched.h
index d62316b..5a9afb4 100644
--- a/include/uapi/linux/pkt_sched.h
+++ b/include/uapi/linux/pkt_sched.h
@@ -772,7 +772,7 @@ enum {
TCA_FQ_BUCKETS_LOG, /* log2(number of buckets) */
- TCA_FQ_FLOW_REFILL_DELAY, /* flow credit refill delay in usec */
+ TCA_FQ_FLOW_REFILL_DELAY, /* obsolete, do not use */
__TCA_FQ_MAX
};
diff --git a/net/sched/sch_fq.c b/net/sched/sch_fq.c
index 6f0c45e..81695ac 100644
--- a/net/sched/sch_fq.c
+++ b/net/sched/sch_fq.c
@@ -90,7 +90,6 @@ struct fq_sched_data {
struct fq_flow internal; /* for non classified or high prio packets */
u32 quantum;
u32 initial_quantum;
- u32 flow_refill_delay;
u32 flow_max_rate; /* optional max rate per flow */
u32 flow_plimit; /* max packets per flow */
struct rb_root *fq_root;
@@ -377,10 +376,6 @@ static int fq_enqueue(struct sk_buff *skb, struct Qdisc *sch)
qdisc_qstats_backlog_inc(sch, skb);
if (fq_flow_is_detached(f)) {
fq_flow_add_tail(&q->new_flows, f);
- if (time_after(jiffies, f->age + q->flow_refill_delay)) {
- f->credit = max_t(u32, f->credit, q->quantum);
- f->time_credit_filled = ktime_get_ns();
- }
q->inactive_flows--;
}
@@ -701,11 +696,9 @@ static int fq_change(struct Qdisc *sch, struct nlattr *opt)
err = -EINVAL;
}
- if (tb[TCA_FQ_FLOW_REFILL_DELAY]) {
- u32 usecs_delay = nla_get_u32(tb[TCA_FQ_FLOW_REFILL_DELAY]) ;
-
- q->flow_refill_delay = usecs_to_jiffies(usecs_delay);
- }
+ if (tb[TCA_FQ_FLOW_REFILL_DELAY])
+ pr_warn_ratelimited("sch_fq: refill delay %u ignored.\n",
+ nla_get_u32(tb[TCA_FQ_FLOW_REFILL_DELAY]));
if (!err) {
sch_tree_unlock(sch);
@@ -744,7 +737,6 @@ static int fq_init(struct Qdisc *sch, struct nlattr *opt)
q->flow_plimit = 100;
q->quantum = 2 * psched_mtu(qdisc_dev(sch));
q->initial_quantum = 10 * psched_mtu(qdisc_dev(sch));
- q->flow_refill_delay = msecs_to_jiffies(40);
q->flow_max_rate = ~0U;
q->rate_enable = 1;
q->new_flows.first = NULL;
@@ -771,7 +763,9 @@ static int fq_dump(struct Qdisc *sch, struct sk_buff *skb)
if (opts == NULL)
goto nla_put_failure;
- /* TCA_FQ_FLOW_DEFAULT_RATE is not used anymore */
+ /* TCA_FQ_FLOW_DEFAULT_RATE and TCA_FQ_FLOW_REFILL_DELAY
+ * is not used anymore.
+ */
if (nla_put_u32(skb, TCA_FQ_PLIMIT, sch->limit) ||
nla_put_u32(skb, TCA_FQ_FLOW_PLIMIT, q->flow_plimit) ||
@@ -779,8 +773,6 @@ static int fq_dump(struct Qdisc *sch, struct sk_buff *skb)
nla_put_u32(skb, TCA_FQ_INITIAL_QUANTUM, q->initial_quantum) ||
nla_put_u32(skb, TCA_FQ_RATE_ENABLE, q->rate_enable) ||
nla_put_u32(skb, TCA_FQ_FLOW_MAX_RATE, q->flow_max_rate) ||
- nla_put_u32(skb, TCA_FQ_FLOW_REFILL_DELAY,
- jiffies_to_usecs(q->flow_refill_delay)) ||
nla_put_u32(skb, TCA_FQ_BUCKETS_LOG, q->fq_trees_log))
goto nla_put_failure;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH net-next 1/2] pkt_sched: fq: avoid artificial bursts for clocked flows
From: Eric Dumazet @ 2015-02-02 19:24 UTC (permalink / raw)
To: Kenneth Klette Jonassen; +Cc: netdev
In-Reply-To: <1422903556-30393-1-git-send-email-kennetkl@ifi.uio.no>
On Mon, 2015-02-02 at 19:59 +0100, Kenneth Klette Jonassen wrote:
> Current pacing behavior always throttle flows for a time equal to one full
> quantum, starting at the instance in time when a flow depletes its credit.
> This is optimal for burst sizes that are a multiple of the chosen quantum.
>
> For flows with many small and evenly clocked packets, the depletion and
> refilling of credits cause packets to queue and transmit in bursts, even
> when their clocked rate is below the pacing rate. With TCP ACKs, this
> artificial queueing induces significant noise to RTTs, e.g. up to 2.07 ms
> for rtt 20 ms, cwnd 10 and quantum 3028.
>
> Packetdrill script to illustrate bursts:
> 0.000 socket(..., SOCK_DGRAM, IPPROTO_UDP) = 3
> 0.000 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
> 0.000 bind(3, ..., ...) = 0
> 0.000 connect(3, ..., ...) = 0
>
> // SO_MAX_PACING_RATE: 2500 Bps, 100 ms per quantum, 20 ms per 50B packet.
> 0.000 setsockopt(3, SOL_SOCKET, 47, [2500], 4) = 0
> 0.000 `tc qdisc add dev tun0 root fq initial_quantum 250 quantum 250`
>
> // Use 200 credits: send four perfectly spaced 50 byte packets.
> 0.000 write(3, ..., 22) = 22
> 0.000 > udp (22)
> 0.020 write(3, ..., 22) = 22
> 0.020 > udp (22)
> 0.040 write(3, ..., 22) = 22
> 0.040 > udp (22)
> 0.060 write(3, ..., 22) = 22
> 0.060 > udp (22)
We do not want to perfectly space packets, but have an efficient packet
scheduler, allowing TCP pacing.
I chose to not use ktime_get() in enqueue() when I wrote sch_fq.
A Token Bucket Filter has the notion of quantum, meaning you configure
the granularity given this quantum.
At Google, we have a special handling for TCP ACK packets, so that they
do not interfere with FQ/pacing.
ACK packets are not paced, ever.
This patch also allows skb->ooo_okay being set even if the DATA packet
immediately follows a train of ACK packets (as in typical RPC patterns)
^ permalink raw reply
* Re: [PATCHv3, ipsec-next] xfrm: Do not parse 32bits compiled xfrm netlink msg on 64bits host
From: David Miller @ 2015-02-02 19:45 UTC (permalink / raw)
To: nicolas.dichtel
Cc: steffen.klassert, fan.du, herbert, netdev, fengyuleidian0615
In-Reply-To: <54CF3D3A.5040607@6wind.com>
From: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date: Mon, 02 Feb 2015 10:02:50 +0100
> Le 02/02/2015 09:44, Steffen Klassert a écrit :
>> On Thu, Jan 29, 2015 at 11:29:51AM +0100, Nicolas Dichtel wrote:
> [snip]
>>>
>>> The point I try to make is that patching userland apps allows to use
>>> xfrm on a
>>> 32bits userland / 64bits kernel.
>>
>> Ugh, I did not know that this is used that way. Which applications do
>> this?
>> So the situation is worse than I thought. What happens to such
>> applications
>> if we add a compat layer in the kernel? I'd guess they will break,
>> right?
>
> A compat layer will be perfect. I just wanted to highlight the fact
> that without this patch, it's possible to have a workaround to use
> netlink-xfrm and after it, it will be impossible.
Just a little history, there was a case where we tried to work around this
in userspace by messing with the structure definitions when building
the userland binaries, and that completely exploded. This was with
the wireless extensions about 15 years ago.
If you work around it in userspace, then you can't fix the kernel to
do the right thing without potentially breaking things again for
the work around binaries that have been created.
^ permalink raw reply
* [PATCH] bluetooth: hci_sock: Use type cast "(void *)" to avoid building warnings
From: Chen Gang S @ 2015-02-02 20:37 UTC (permalink / raw)
To: marcel-kz+m5ild9QBg9hUCZPvPmw, gustavo-THi1TnShQwVAfugRpC6u6w,
johan.hedberg-Re5JQEeQqe8AvxtiuMwx3w, David S. Miller
Cc: linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
The related warning (with allmodconfig under xtensa):
net/bluetooth/hci_sock.c: In function 'hci_sock_sendmsg':
net/bluetooth/hci_sock.c:955:8: warning: passing argument 2 of 'hci_test_bit' discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
&hci_sec_filter.ocf_mask[ogf])) &&
^
net/bluetooth/hci_sock.c:49:19: note: expected 'void *' but argument is of type 'const __u32 (*)[4] {aka const unsigned int (*)[4]}'
static inline int hci_test_bit(int nr, void *addr)
^
Signed-off-by: Chen Gang <gang.chen.5i5j-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
net/bluetooth/hci_sock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/bluetooth/hci_sock.c b/net/bluetooth/hci_sock.c
index 1d65c5b..80c5a79 100644
--- a/net/bluetooth/hci_sock.c
+++ b/net/bluetooth/hci_sock.c
@@ -952,7 +952,7 @@ static int hci_sock_sendmsg(struct kiocb *iocb, struct socket *sock,
if (((ogf > HCI_SFLT_MAX_OGF) ||
!hci_test_bit(ocf & HCI_FLT_OCF_BITS,
- &hci_sec_filter.ocf_mask[ogf])) &&
+ (void *)&hci_sec_filter.ocf_mask[ogf])) &&
!capable(CAP_NET_RAW)) {
err = -EPERM;
goto drop;
--
1.9.3
^ permalink raw reply related
* Re: [PATCH] bluetooth: hci_sock: Use type cast "(void *)" to avoid building warnings
From: Joe Perches @ 2015-02-02 20:39 UTC (permalink / raw)
To: Chen Gang S
Cc: marcel, gustavo, johan.hedberg, David S. Miller, linux-bluetooth,
netdev@vger.kernel.org
In-Reply-To: <54CFE01D.5090309@sunrus.com.cn>
On Tue, 2015-02-03 at 04:37 +0800, Chen Gang S wrote:
> The related warning (with allmodconfig under xtensa):
[]
> diff --git a/net/bluetooth/hci_sock.c b/net/bluetooth/hci_sock.c
[]
> @@ -952,7 +952,7 @@ static int hci_sock_sendmsg(struct kiocb *iocb, struct socket *sock,
>
> if (((ogf > HCI_SFLT_MAX_OGF) ||
> !hci_test_bit(ocf & HCI_FLT_OCF_BITS,
> - &hci_sec_filter.ocf_mask[ogf])) &&
> + (void *)&hci_sec_filter.ocf_mask[ogf])) &&
> !capable(CAP_NET_RAW)) {
> err = -EPERM;
> goto drop;
Probably better to change the hci_test_bit to take const void *
static inline int hci_test_bit(int nr, void *addr)
{
return *((__u32 *) addr + (nr >> 5)) & ((__u32) 1 << (nr & 31));
}
^ permalink raw reply
* Re: [PATCH net-next 0/3] openvswitch: Add STT support.
From: Jesse Gross @ 2015-02-02 20:39 UTC (permalink / raw)
To: Tom Herbert; +Cc: Pravin Shelar, David Miller, Linux Netdev List
In-Reply-To: <CA+mtBx8mQ4ai3mbY4=HrKjximaEe-+ui2uEqeunQ3kOG=YNBpA@mail.gmail.com>
On Mon, Feb 2, 2015 at 8:23 AM, Tom Herbert <therbert@google.com> wrote:
>> I would recommend you take a look at the draft if you haven't already:
>> http://tools.ietf.org/html/draft-davie-stt-06
>>
>> It is currently in the final stages of the RFC publication process.
>
> Sorry, but this statement is completely wrong and misleading.
> According to datatracker this draft has been expired since October,
> there's been no discussion on it in IETF, and this has not gone to
> IESG. You cannot say this is an IETF standard nor that it is about to
> be published as one. See
> https://datatracker.ietf.org/doc/draft-davie-stt/ and please read the
> Internet Standards process in RFC2026.
>
> I suggest that you update the draft and post it on both nvo3 and tsvwg
> so there can be some real discussion on the implications of
> repurposing an IP protocol number and breaking TCP protocol standards.
Seriously, Tom?
It's currently in the ISE queue to be published as an RFC, which you
can see in the history in the datatracker link. I didn't say that it
was being published as a standard, I said RFC. This is the same
process and status that VXLAN has.. It also was presented in nvo3
before you started coming.
Please get your facts straight before making accusations.
^ permalink raw reply
* Re: [PATCH net-next 5/6] udpv6: Add lockless sendmsg() support
From: Vlad Yasevich @ 2015-02-02 20:42 UTC (permalink / raw)
To: Sergei Shtylyov, netdev; +Cc: herbert, hannes, Vladislav Yasevich
In-Reply-To: <54CD3FF4.1030007@cogentembedded.com>
On 01/31/2015 03:49 PM, Sergei Shtylyov wrote:
> Hello.
>
> On 1/31/2015 6:40 PM, Vladislav Yasevich wrote:
>
>> This commit adds the same functionaliy to IPv6 that
>> commit 903ab86d195cca295379699299c5fc10beba31c7
>> Author: Herbert Xu <herbert@gondor.apana.org.au>
>> Date: Tue Mar 1 02:36:48 2011 +0000
>
>> udp: Add lockless transmit path
>
>> added to IPv4.
>
>> UDP transmit path can now run without a socket lock,
>> thus allowing multiple threads to send to a single socket
>> more efficiently.
>> This is only used when corking/MSG_MORE is not used.
>
>> Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com>
>> ---
>> net/ipv6/udp.c | 24 ++++++++++++++++++++----
>> 1 file changed, 20 insertions(+), 4 deletions(-)
>
>> diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
>> index 67a3d70..d048d46 100644
>> --- a/net/ipv6/udp.c
>> +++ b/net/ipv6/udp.c
> [...]
>> @@ -1307,6 +1308,20 @@ do_udp_sendmsg:
>> goto do_confirm;
>> back_from_confirm:
>>
>> + /* Lockless fast path for the non-corking case */
>> + if (!corkreq) {
>> + struct sk_buff *skb;
>>
>> + skb = ip6_make_skb(sk, getfrag, msg, ulen,
>> + sizeof(struct udphdr), hlimit, tclass, opt,
>> + &fl6, (struct rt6_info *)dst,
>> + msg->msg_flags, dontfrag);
>> + err = PTR_ERR(skb);
>
> You should use PTR_ERR_OR_ZERO() here, I think.
>
That particular code was stolen from ipv4/udp.c. You are
right, we can use PTR_ERR_OR_ZERO() and simplify the following
check as well.
Will fix.
Thanks
-vlad
> [...]
>
> WBR, Sergei
>
^ permalink raw reply
* Re: [PATCH] bluetooth: hci_sock: Use type cast "(void *)" to avoid building warnings
From: Chen Gang S @ 2015-02-02 21:07 UTC (permalink / raw)
To: Joe Perches
Cc: marcel, gustavo, johan.hedberg, David S. Miller, linux-bluetooth,
netdev@vger.kernel.org
In-Reply-To: <1422909598.30476.20.camel@perches.com>
On 2/3/15 04:39, Joe Perches wrote:
> On Tue, 2015-02-03 at 04:37 +0800, Chen Gang S wrote:
>> The related warning (with allmodconfig under xtensa):
> []
>> diff --git a/net/bluetooth/hci_sock.c b/net/bluetooth/hci_sock.c
> []
>> @@ -952,7 +952,7 @@ static int hci_sock_sendmsg(struct kiocb *iocb, struct socket *sock,
>>
>> if (((ogf > HCI_SFLT_MAX_OGF) ||
>> !hci_test_bit(ocf & HCI_FLT_OCF_BITS,
>> - &hci_sec_filter.ocf_mask[ogf])) &&
>> + (void *)&hci_sec_filter.ocf_mask[ogf])) &&
>> !capable(CAP_NET_RAW)) {
>> err = -EPERM;
>> goto drop;
>
> Probably better to change the hci_test_bit to take const void *
>
> static inline int hci_test_bit(int nr, void *addr)
> {
> return *((__u32 *) addr + (nr >> 5)) & ((__u32) 1 << (nr & 31));
> }
>
Yeah, thanks. It should be fixed like what you said above, I shall send
patch v2 for it.
Thanks.
--
Chen Gang
Open, share, and attitude like air, water, and life which God blessed
^ permalink raw reply
* [PATCH] net: usb: sr9700: Use 'SR_' prefix for the common register macros
From: Chen Gang S @ 2015-02-02 21:00 UTC (permalink / raw)
To: linux-usb, netdev, linux-kernel@vger.kernel.org
The commone register macors (e.g. RSR) is too commont to drivers, it may
be conflict with the architectures (e.g. xtensa, sh).
The related warnings (with allmodconfig under xtensa):
CC [M] drivers/net/usb/sr9700.o
In file included from drivers/net/usb/sr9700.c:24:0:
drivers/net/usb/sr9700.h:65:0: warning: "RSR" redefined
#define RSR 0x06
^
In file included from ./arch/xtensa/include/asm/bitops.h:22:0,
from include/linux/bitops.h:36,
from include/linux/kernel.h:10,
from include/linux/list.h:8,
from include/linux/module.h:9,
from drivers/net/usb/sr9700.c:13:
./arch/xtensa/include/asm/processor.h:190:0: note: this is the location of the previous definition
#define RSR(v,sr) __asm__ __volatile__ ("rsr %0,"__stringify(sr) : "=a"(v));
^
Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
---
drivers/net/usb/sr9700.c | 36 +++++++++++++-------------
drivers/net/usb/sr9700.h | 66 ++++++++++++++++++++++++------------------------
2 files changed, 51 insertions(+), 51 deletions(-)
diff --git a/drivers/net/usb/sr9700.c b/drivers/net/usb/sr9700.c
index 99b69af..4a1e9c4 100644
--- a/drivers/net/usb/sr9700.c
+++ b/drivers/net/usb/sr9700.c
@@ -77,7 +77,7 @@ static int wait_phy_eeprom_ready(struct usbnet *dev, int phy)
int ret;
udelay(1);
- ret = sr_read_reg(dev, EPCR, &tmp);
+ ret = sr_read_reg(dev, SR_EPCR, &tmp);
if (ret < 0)
return ret;
@@ -98,15 +98,15 @@ static int sr_share_read_word(struct usbnet *dev, int phy, u8 reg,
mutex_lock(&dev->phy_mutex);
- sr_write_reg(dev, EPAR, phy ? (reg | EPAR_PHY_ADR) : reg);
- sr_write_reg(dev, EPCR, phy ? (EPCR_EPOS | EPCR_ERPRR) : EPCR_ERPRR);
+ sr_write_reg(dev, SR_EPAR, phy ? (reg | EPAR_PHY_ADR) : reg);
+ sr_write_reg(dev, SR_EPCR, phy ? (EPCR_EPOS | EPCR_ERPRR) : EPCR_ERPRR);
ret = wait_phy_eeprom_ready(dev, phy);
if (ret < 0)
goto out_unlock;
- sr_write_reg(dev, EPCR, 0x0);
- ret = sr_read(dev, EPDR, 2, value);
+ sr_write_reg(dev, SR_EPCR, 0x0);
+ ret = sr_read(dev, SR_EPDR, 2, value);
netdev_dbg(dev->net, "read shared %d 0x%02x returned 0x%04x, %d\n",
phy, reg, *value, ret);
@@ -123,19 +123,19 @@ static int sr_share_write_word(struct usbnet *dev, int phy, u8 reg,
mutex_lock(&dev->phy_mutex);
- ret = sr_write(dev, EPDR, 2, &value);
+ ret = sr_write(dev, SR_EPDR, 2, &value);
if (ret < 0)
goto out_unlock;
- sr_write_reg(dev, EPAR, phy ? (reg | EPAR_PHY_ADR) : reg);
- sr_write_reg(dev, EPCR, phy ? (EPCR_WEP | EPCR_EPOS | EPCR_ERPRW) :
+ sr_write_reg(dev, SR_EPAR, phy ? (reg | EPAR_PHY_ADR) : reg);
+ sr_write_reg(dev, SR_EPCR, phy ? (EPCR_WEP | EPCR_EPOS | EPCR_ERPRW) :
(EPCR_WEP | EPCR_ERPRW));
ret = wait_phy_eeprom_ready(dev, phy);
if (ret < 0)
goto out_unlock;
- sr_write_reg(dev, EPCR, 0x0);
+ sr_write_reg(dev, SR_EPCR, 0x0);
out_unlock:
mutex_unlock(&dev->phy_mutex);
@@ -188,7 +188,7 @@ static int sr_mdio_read(struct net_device *netdev, int phy_id, int loc)
if (loc == MII_BMSR) {
u8 value;
- sr_read_reg(dev, NSR, &value);
+ sr_read_reg(dev, SR_NSR, &value);
if (value & NSR_LINKST)
rc = 1;
}
@@ -228,7 +228,7 @@ static u32 sr9700_get_link(struct net_device *netdev)
int rc = 0;
/* Get the Link Status directly */
- sr_read_reg(dev, NSR, &value);
+ sr_read_reg(dev, SR_NSR, &value);
if (value & NSR_LINKST)
rc = 1;
@@ -281,8 +281,8 @@ static void sr9700_set_multicast(struct net_device *netdev)
}
}
- sr_write_async(dev, MAR, SR_MCAST_SIZE, hashes);
- sr_write_reg_async(dev, RCR, rx_ctl);
+ sr_write_async(dev, SR_MAR, SR_MCAST_SIZE, hashes);
+ sr_write_reg_async(dev, SR_RCR, rx_ctl);
}
static int sr9700_set_mac_address(struct net_device *netdev, void *p)
@@ -297,7 +297,7 @@ static int sr9700_set_mac_address(struct net_device *netdev, void *p)
}
memcpy(netdev->dev_addr, addr->sa_data, netdev->addr_len);
- sr_write_async(dev, PAR, 6, netdev->dev_addr);
+ sr_write_async(dev, SR_PAR, 6, netdev->dev_addr);
return 0;
}
@@ -340,7 +340,7 @@ static int sr9700_bind(struct usbnet *dev, struct usb_interface *intf)
mii->phy_id_mask = 0x1f;
mii->reg_num_mask = 0x1f;
- sr_write_reg(dev, NCR, NCR_RST);
+ sr_write_reg(dev, SR_NCR, NCR_RST);
udelay(20);
/* read MAC
@@ -348,17 +348,17 @@ static int sr9700_bind(struct usbnet *dev, struct usb_interface *intf)
* EEPROM automatically to PAR. In case there is no EEPROM externally,
* a default MAC address is stored in PAR for making chip work properly.
*/
- if (sr_read(dev, PAR, ETH_ALEN, netdev->dev_addr) < 0) {
+ if (sr_read(dev, SR_PAR, ETH_ALEN, netdev->dev_addr) < 0) {
netdev_err(netdev, "Error reading MAC address\n");
ret = -ENODEV;
goto out;
}
/* power up and reset phy */
- sr_write_reg(dev, PRR, PRR_PHY_RST);
+ sr_write_reg(dev, SR_PRR, PRR_PHY_RST);
/* at least 10ms, here 20ms for safe */
mdelay(20);
- sr_write_reg(dev, PRR, 0);
+ sr_write_reg(dev, SR_PRR, 0);
/* at least 1ms, here 2ms for reading right register */
udelay(2 * 1000);
diff --git a/drivers/net/usb/sr9700.h b/drivers/net/usb/sr9700.h
index fd687c5..258b030 100644
--- a/drivers/net/usb/sr9700.h
+++ b/drivers/net/usb/sr9700.h
@@ -14,13 +14,13 @@
/* sr9700 spec. register table on Linux platform */
/* Network Control Reg */
-#define NCR 0x00
+#define SR_NCR 0x00
#define NCR_RST (1 << 0)
#define NCR_LBK (3 << 1)
#define NCR_FDX (1 << 3)
#define NCR_WAKEEN (1 << 6)
/* Network Status Reg */
-#define NSR 0x01
+#define SR_NSR 0x01
#define NSR_RXRDY (1 << 0)
#define NSR_RXOV (1 << 1)
#define NSR_TX1END (1 << 2)
@@ -30,7 +30,7 @@
#define NSR_LINKST (1 << 6)
#define NSR_SPEED (1 << 7)
/* Tx Control Reg */
-#define TCR 0x02
+#define SR_TCR 0x02
#define TCR_CRC_DIS (1 << 1)
#define TCR_PAD_DIS (1 << 2)
#define TCR_LC_CARE (1 << 3)
@@ -38,7 +38,7 @@
#define TCR_EXCECM (1 << 5)
#define TCR_LF_EN (1 << 6)
/* Tx Status Reg for Packet Index 1 */
-#define TSR1 0x03
+#define SR_TSR1 0x03
#define TSR1_EC (1 << 2)
#define TSR1_COL (1 << 3)
#define TSR1_LC (1 << 4)
@@ -46,7 +46,7 @@
#define TSR1_LOC (1 << 6)
#define TSR1_TLF (1 << 7)
/* Tx Status Reg for Packet Index 2 */
-#define TSR2 0x04
+#define SR_TSR2 0x04
#define TSR2_EC (1 << 2)
#define TSR2_COL (1 << 3)
#define TSR2_LC (1 << 4)
@@ -54,7 +54,7 @@
#define TSR2_LOC (1 << 6)
#define TSR2_TLF (1 << 7)
/* Rx Control Reg*/
-#define RCR 0x05
+#define SR_RCR 0x05
#define RCR_RXEN (1 << 0)
#define RCR_PRMSC (1 << 1)
#define RCR_RUNT (1 << 2)
@@ -62,87 +62,87 @@
#define RCR_DIS_CRC (1 << 4)
#define RCR_DIS_LONG (1 << 5)
/* Rx Status Reg */
-#define RSR 0x06
+#define SR_RSR 0x06
#define RSR_AE (1 << 2)
#define RSR_MF (1 << 6)
#define RSR_RF (1 << 7)
/* Rx Overflow Counter Reg */
-#define ROCR 0x07
+#define SR_ROCR 0x07
#define ROCR_ROC (0x7F << 0)
#define ROCR_RXFU (1 << 7)
/* Back Pressure Threshold Reg */
-#define BPTR 0x08
+#define SR_BPTR 0x08
#define BPTR_JPT (0x0F << 0)
#define BPTR_BPHW (0x0F << 4)
/* Flow Control Threshold Reg */
-#define FCTR 0x09
+#define SR_FCTR 0x09
#define FCTR_LWOT (0x0F << 0)
#define FCTR_HWOT (0x0F << 4)
/* rx/tx Flow Control Reg */
-#define FCR 0x0A
+#define SR_FCR 0x0A
#define FCR_FLCE (1 << 0)
#define FCR_BKPA (1 << 4)
#define FCR_TXPEN (1 << 5)
#define FCR_TXPF (1 << 6)
#define FCR_TXP0 (1 << 7)
/* Eeprom & Phy Control Reg */
-#define EPCR 0x0B
+#define SR_EPCR 0x0B
#define EPCR_ERRE (1 << 0)
#define EPCR_ERPRW (1 << 1)
#define EPCR_ERPRR (1 << 2)
#define EPCR_EPOS (1 << 3)
#define EPCR_WEP (1 << 4)
/* Eeprom & Phy Address Reg */
-#define EPAR 0x0C
+#define SR_EPAR 0x0C
#define EPAR_EROA (0x3F << 0)
#define EPAR_PHY_ADR_MASK (0x03 << 6)
#define EPAR_PHY_ADR (0x01 << 6)
/* Eeprom & Phy Data Reg */
-#define EPDR 0x0D /* 0x0D ~ 0x0E for Data Reg Low & High */
+#define SR_EPDR 0x0D /* 0x0D ~ 0x0E for Data Reg Low & High */
/* Wakeup Control Reg */
-#define WCR 0x0F
+#define SR_WCR 0x0F
#define WCR_MAGICST (1 << 0)
#define WCR_LINKST (1 << 2)
#define WCR_MAGICEN (1 << 3)
#define WCR_LINKEN (1 << 5)
/* Physical Address Reg */
-#define PAR 0x10 /* 0x10 ~ 0x15 6 bytes for PAR */
+#define SR_PAR 0x10 /* 0x10 ~ 0x15 6 bytes for PAR */
/* Multicast Address Reg */
-#define MAR 0x16 /* 0x16 ~ 0x1D 8 bytes for MAR */
+#define SR_MAR 0x16 /* 0x16 ~ 0x1D 8 bytes for MAR */
/* 0x1e unused */
/* Phy Reset Reg */
-#define PRR 0x1F
+#define SR_PRR 0x1F
#define PRR_PHY_RST (1 << 0)
/* Tx sdram Write Pointer Address Low */
-#define TWPAL 0x20
+#define SR_TWPAL 0x20
/* Tx sdram Write Pointer Address High */
-#define TWPAH 0x21
+#define SR_TWPAH 0x21
/* Tx sdram Read Pointer Address Low */
-#define TRPAL 0x22
+#define SR_TRPAL 0x22
/* Tx sdram Read Pointer Address High */
-#define TRPAH 0x23
+#define SR_TRPAH 0x23
/* Rx sdram Write Pointer Address Low */
-#define RWPAL 0x24
+#define SR_RWPAL 0x24
/* Rx sdram Write Pointer Address High */
-#define RWPAH 0x25
+#define SR_RWPAH 0x25
/* Rx sdram Read Pointer Address Low */
-#define RRPAL 0x26
+#define SR_RRPAL 0x26
/* Rx sdram Read Pointer Address High */
-#define RRPAH 0x27
+#define SR_RRPAH 0x27
/* Vendor ID register */
-#define VID 0x28 /* 0x28 ~ 0x29 2 bytes for VID */
+#define SR_VID 0x28 /* 0x28 ~ 0x29 2 bytes for VID */
/* Product ID register */
-#define PID 0x2A /* 0x2A ~ 0x2B 2 bytes for PID */
+#define SR_PID 0x2A /* 0x2A ~ 0x2B 2 bytes for PID */
/* CHIP Revision register */
-#define CHIPR 0x2C
+#define SR_CHIPR 0x2C
/* 0x2D --> 0xEF unused */
/* USB Device Address */
-#define USBDA 0xF0
+#define SR_USBDA 0xF0
#define USBDA_USBFA (0x7F << 0)
/* RX packet Counter Reg */
-#define RXC 0xF1
+#define SR_RXC 0xF1
/* Tx packet Counter & USB Status Reg */
-#define TXC_USBS 0xF2
+#define SR_TXC_USBS 0xF2
#define TXC_USBS_TXC0 (1 << 0)
#define TXC_USBS_TXC1 (1 << 1)
#define TXC_USBS_TXC2 (1 << 2)
@@ -150,7 +150,7 @@
#define TXC_USBS_SUSFLAG (1 << 6)
#define TXC_USBS_RXFAULT (1 << 7)
/* USB Control register */
-#define USBC 0xF4
+#define SR_USBC 0xF4
#define USBC_EP3NAK (1 << 4)
#define USBC_EP3ACK (1 << 5)
--
1.9.3
^ permalink raw reply related
* Per-connection tcp_retries2 and RFC 1122 compliance
From: John Eckersberg @ 2015-02-02 21:05 UTC (permalink / raw)
To: netdev
Greetings,
RFC 1122, section 4.2.3.5 "TCP Connection Failures", states:
(d) An application MUST be able to set the value for R2 for
a particular connection. For example, an interactive
application might set R2 to "infinity," giving the user
control over when to disconnect.
The R2 value referenced above is implemented as the tcp_retries2 sysctl.
However it seems that the only way to tune that value is via the global
sysctl knob. In other words, there is no provided way to set it only
for a particular connection as RFC 1122 requires.
Could someone confirm that this is a legitimate bug/deficiency? Or am I
just missing something? If this is a real bug, I would be willing to
put a patch together to fix it although I will probably require some
handholding (this would be my first contribution to the kernel).
Thanks,
John
^ permalink raw reply
* Re: [PATCH v3 0/3] Restore UFO support to virtio_net devices
From: David Miller @ 2015-02-02 21:11 UTC (permalink / raw)
To: vyasevich; +Cc: eric.dumazet, mst, netdev, virtualization, hannes, ben
In-Reply-To: <1422889269-16007-1-git-send-email-vyasevic@redhat.com>
Vlad, this still fails the same way.
[davem@dokdo net]$ make -s -j8
kernel/Makefile:132: *** No X.509 certificates found ***
kernel/Makefile:132: *** No X.509 certificates found ***
net/built-in.o: In function `udp6_ufo_fragment':
udp_offload.c:(.text+0x103514): undefined reference to `ipv6_select_ident'
make: *** [vmlinux] Error 1
You're putting ipv6_select_ident() into the ipv6 module via
ip6_output.c, but that means that code like udp_offload.c which is
built statically into the kernel can't see the symbol.
Please build allmodconfig, that is the exact build I use to test your
and everyone else's changes.
^ permalink raw reply
* Re: [PATCH net-next 2/8] cxgb4: Added support in debugfs to display tp_la stats
From: David Miller @ 2015-02-02 21:14 UTC (permalink / raw)
To: hariprasad; +Cc: netdev, leedom, anish, nirranjan, praveenm
In-Reply-To: <1422888789-12016-3-git-send-email-hariprasad@chelsio.com>
From: Hariprasad Shenai <hariprasad@chelsio.com>
Date: Mon, 2 Feb 2015 20:23:03 +0530
> Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
Ok I've seen enough.
You guys really, truly, abuse debugfs. So I'm putting my foot down now.
Stats like this can be exported through traditional means such as via
ethtool.
^ permalink raw reply
* [PATCH v2] net: bluetooth: hci_sock: Use 'const void *' instead of 'void *' for 2nd parameter of hci_test_bit()
From: Chen Gang S @ 2015-02-02 21:14 UTC (permalink / raw)
To: marcel-kz+m5ild9QBg9hUCZPvPmw, gustavo-THi1TnShQwVAfugRpC6u6w,
johan.hedberg-Re5JQEeQqe8AvxtiuMwx3w
Cc: David S. Miller, linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
hci_test_bit() does not modify 2nd parameter, so it is better to let it
be constant, or may cause build warning. The related warning (with
allmodconfig under xtensa):
net/bluetooth/hci_sock.c: In function 'hci_sock_sendmsg':
net/bluetooth/hci_sock.c:955:8: warning: passing argument 2 of 'hci_test_bit' discards 'const' qualifier from pointer target type [-Wdiscarded-array-qualifiers]
&hci_sec_filter.ocf_mask[ogf])) &&
^
net/bluetooth/hci_sock.c:49:19: note: expected 'void *' but argument is of type 'const __u32 (*)[4] {aka const unsigned int (*)[4]}'
static inline int hci_test_bit(int nr, void *addr)
^
Signed-off-by: Chen Gang <gang.chen.5i5j-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
net/bluetooth/hci_sock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/bluetooth/hci_sock.c b/net/bluetooth/hci_sock.c
index 80c5a79..858b53a 100644
--- a/net/bluetooth/hci_sock.c
+++ b/net/bluetooth/hci_sock.c
@@ -46,7 +46,7 @@ struct hci_pinfo {
unsigned short channel;
};
-static inline int hci_test_bit(int nr, void *addr)
+static inline int hci_test_bit(int nr, const void *addr)
{
return *((__u32 *) addr + (nr >> 5)) & ((__u32) 1 << (nr & 31));
}
--
1.9.3
^ permalink raw reply related
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