* Re: [PATCH] crypto: aesni-intel - avoid IPsec re-ordering
From: Steffen Klassert @ 2014-11-20 7:59 UTC (permalink / raw)
To: Herbert Xu; +Cc: Ming Liu, davem, ying.xue, linux-crypto, netdev
In-Reply-To: <20141120074342.GA29544@gondor.apana.org.au>
On Thu, Nov 20, 2014 at 03:43:42PM +0800, Herbert Xu wrote:
> On Thu, Nov 20, 2014 at 08:26:51AM +0100, Steffen Klassert wrote:
> >
> > What about to use a fallback algorithm that does not need to touch
> > FPU/SIMD in such cases? We would not need cryptd at all and it would
> > keep the requests in the right order because we don't defer them.
>
> This would be bad for throughput since the fallback is many orders
> of magnitude slower than aesni.
Sure, but could be an option if this is really a rare case.
Anyway, I don't mind too much about the solution as long as we
get it to work :)
^ permalink raw reply
* Re: [PATCH] crypto: aesni-intel - avoid IPsec re-ordering
From: Herbert Xu @ 2014-11-20 7:43 UTC (permalink / raw)
To: Steffen Klassert; +Cc: Ming Liu, davem, ying.xue, linux-crypto, netdev
In-Reply-To: <20141120072650.GT6390@secunet.com>
On Thu, Nov 20, 2014 at 08:26:51AM +0100, Steffen Klassert wrote:
>
> What about to use a fallback algorithm that does not need to touch
> FPU/SIMD in such cases? We would not need cryptd at all and it would
> keep the requests in the right order because we don't defer them.
This would be bad for throughput since the fallback is many orders
of magnitude slower than aesni.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: aesni-intel - avoid IPsec re-ordering
From: Steffen Klassert @ 2014-11-20 7:26 UTC (permalink / raw)
To: Herbert Xu; +Cc: Ming Liu, davem, ying.xue, linux-crypto, netdev
In-Reply-To: <20141115031549.GA19208@gondor.apana.org.au>
On Sat, Nov 15, 2014 at 11:15:50AM +0800, Herbert Xu wrote:
> On Wed, Nov 12, 2014 at 09:41:38AM +0100, Steffen Klassert wrote:
> >
> > Everything below the local_bh_enable() should not run in atomic context
> > as the subsequent functions may set the CRYPTO_TFM_REQ_MAY_SLEEP flag.
>
> Actually I'm thinking of doing exactly that (disabling softirq in
> cryptd) to fix the reordering problem.
>
> Most threads do not use the FPU/SIMD so cryptd is only ever needed
> when we have a user-space app that touches the FPU/SIMD which then
> gets an interrupt to perform crypto in softirq. So forcing cryptd
> on everyone just because some apps touch the FPU/SIMD is a non-
> starter.
>
> The most straightforward solution is to always defer to cryptd once
> it gets started. This is bad because if a rarely used app that
> touches FPU/SIMD runs then we'll end up stuck in cryptd long after
> the app goes away.
>
> So what I'm thinking of is to have the softirq path forcibly regain
> control from cryptd where possible. This is tricky because cryptd
> might be in the middle of processing a request. So that's why I'd
> like to disable softirqs while we're processing a request.
>
What about to use a fallback algorithm that does not need to touch
FPU/SIMD in such cases? We would not need cryptd at all and it would
keep the requests in the right order because we don't defer them.
^ permalink raw reply
* Re: [PATCH net V3] virtio-net: validate features during probe
From: Jason Wang @ 2014-11-20 7:13 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: netdev, linux-kernel, virtualization
In-Reply-To: <20141120070244.GE30994@redhat.com>
On 11/20/2014 03:02 PM, Michael S. Tsirkin wrote:
> On Thu, Nov 20, 2014 at 02:10:35PM +0800, Jason Wang wrote:
>> We currently trigger BUG when VIRTIO_NET_F_CTRL_VQ
>> is not set but one of features depending on it is.
>> That's not a friendly way to report errors to
>> hypervisors.
>> Let's check, and fail probe instead.
>>
>> Cc: Rusty Russell <rusty@rustcorp.com.au>
>> Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
>> Cc: Wanlong Gao <gaowanlong@cn.fujitsu.com>
>> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>> Signed-off-by: Jason Wang <jasowang@redhat.com>
>
> Looks good, minor nits below:
>
>> ---
>> Changes from V2:
>> - only check the features for ctrl vq (this fix the real bug)
>> - better error message and simplify API
>> ---
>> drivers/net/virtio_net.c | 37 +++++++++++++++++++++++++++++++++++++
>> 1 file changed, 37 insertions(+)
>>
>> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
>> index ec2a8b4..a6bcfce 100644
>> --- a/drivers/net/virtio_net.c
>> +++ b/drivers/net/virtio_net.c
>> @@ -1673,6 +1673,40 @@ static const struct attribute_group virtio_net_mrg_rx_group = {
>> };
>> #endif
>>
>> +static bool virtnet_fail_on_feature(struct virtio_device *vdev,
>> + unsigned int fbit,
>> + const char *fname, const char *dname)
>> +{
>> + if (!virtio_has_feature(vdev, fbit))
>> + return false;
>> +
>> + dev_err(&vdev->dev, "Hypervisor bug: advertise feature %s but not %s",
> Well we don't know it's a hypervisor. How about:
> Device bug: advertises feature %s but not %s.
Ok.
>> + fname, dname);
>> +
>> + return true;
>> +}
>> +
>> +#define VIRTNET_FAIL_ON(vdev, fbit, dbit) \
>> + virtnet_fail_on_feature(vdev, fbit, #fbit, #dbit)
> I would pass dbit directly, and supply a string from caller,
> instead if #dbit, this way it can be any string.
Right, this is better.
>> +
>> +static bool virtnet_validate_features(struct virtio_device *vdev)
>> +{
>> + if (!virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ) &&
>> + (VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_CTRL_RX,
>> + VIRTIO_NET_F_CTRL_VQ) ||
>> + VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_CTRL_VLAN,
>> + VIRTIO_NET_F_CTRL_VQ) ||
>> + VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_GUEST_ANNOUNCE,
>> + VIRTIO_NET_F_TRL_VQ) ||
> Typo: VIRTIO_NET_F_CTRL_VQ.
>
>
Wil fix this and post V4.
Thanks
^ permalink raw reply
* Re: [PATCH net V3] virtio-net: validate features during probe
From: Michael S. Tsirkin @ 2014-11-20 7:02 UTC (permalink / raw)
To: Jason Wang; +Cc: netdev, linux-kernel, virtualization
In-Reply-To: <1416463835-7364-1-git-send-email-jasowang@redhat.com>
On Thu, Nov 20, 2014 at 02:10:35PM +0800, Jason Wang wrote:
> We currently trigger BUG when VIRTIO_NET_F_CTRL_VQ
> is not set but one of features depending on it is.
> That's not a friendly way to report errors to
> hypervisors.
> Let's check, and fail probe instead.
>
> Cc: Rusty Russell <rusty@rustcorp.com.au>
> Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
> Cc: Wanlong Gao <gaowanlong@cn.fujitsu.com>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Looks good, minor nits below:
> ---
> Changes from V2:
> - only check the features for ctrl vq (this fix the real bug)
> - better error message and simplify API
> ---
> drivers/net/virtio_net.c | 37 +++++++++++++++++++++++++++++++++++++
> 1 file changed, 37 insertions(+)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index ec2a8b4..a6bcfce 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -1673,6 +1673,40 @@ static const struct attribute_group virtio_net_mrg_rx_group = {
> };
> #endif
>
> +static bool virtnet_fail_on_feature(struct virtio_device *vdev,
> + unsigned int fbit,
> + const char *fname, const char *dname)
> +{
> + if (!virtio_has_feature(vdev, fbit))
> + return false;
> +
> + dev_err(&vdev->dev, "Hypervisor bug: advertise feature %s but not %s",
Well we don't know it's a hypervisor. How about:
Device bug: advertises feature %s but not %s.
> + fname, dname);
> +
> + return true;
> +}
> +
> +#define VIRTNET_FAIL_ON(vdev, fbit, dbit) \
> + virtnet_fail_on_feature(vdev, fbit, #fbit, #dbit)
I would pass dbit directly, and supply a string from caller,
instead if #dbit, this way it can be any string.
> +
> +static bool virtnet_validate_features(struct virtio_device *vdev)
> +{
> + if (!virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ) &&
> + (VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_CTRL_RX,
> + VIRTIO_NET_F_CTRL_VQ) ||
> + VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_CTRL_VLAN,
> + VIRTIO_NET_F_CTRL_VQ) ||
> + VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_GUEST_ANNOUNCE,
> + VIRTIO_NET_F_TRL_VQ) ||
Typo: VIRTIO_NET_F_CTRL_VQ.
> + VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_MQ, VIRTIO_NET_F_CTRL_VQ) ||
> + VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_CTRL_MAC_ADDR,
> + VIRTIO_NET_F_CTRL_VQ))) {
> + return false;
> + }
> +
> + return true;
> +}
> +
> static int virtnet_probe(struct virtio_device *vdev)
> {
> int i, err;
> @@ -1680,6 +1714,9 @@ static int virtnet_probe(struct virtio_device *vdev)
> struct virtnet_info *vi;
> u16 max_queue_pairs;
>
> + if (!virtnet_validate_features(vdev))
> + return -EINVAL;
> +
> /* Find if host supports multiqueue virtio_net device */
> err = virtio_cread_feature(vdev, VIRTIO_NET_F_MQ,
> struct virtio_net_config,
> --
> 1.9.1
^ permalink raw reply
* Re: [PATCH] bonding: clear header_ops when last slave detached (v2)
From: Eric Dumazet @ 2014-11-20 6:41 UTC (permalink / raw)
To: Cong Wang; +Cc: Wengang, netdev
In-Reply-To: <CAHA+R7OyA_V149bpE8qUgG9epU-5UG8cf=zOgh5ZXVB3ZFZHUw@mail.gmail.com>
On Wed, 2014-11-19 at 14:26 -0800, Cong Wang wrote:
> On Tue, Nov 18, 2014 at 11:00 PM, Wengang <wen.gang.wang@oracle.com> wrote:
> >
> > Yes, that's true. So the simplest way is move ipoib_header_ops to vmlinux.
> >
>
> That is not an option. Perhaps you need RCU to protect the dev->header_ops
> pointer.
This _is_ a reasonable option, especially for stable kernels
ipoib_hard_header() is 100 bytes or less. Adding infrastructure all over
the kernel to be able to use RCU or module refcounting will cost much
more.
Tell me why it is ok for eth_header_ops() being static (while its _much_
bigger), and not for ipoib_header_ops. This looks pretty arbitrary to
me.
^ permalink raw reply
* Re: [PATCH net] tcp: fix connect() invalid -EADDRNOTAVAIL error
From: Eric Dumazet @ 2014-11-20 6:33 UTC (permalink / raw)
To: Jonathan Maxwell
Cc: davem, kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel,
Jon Maxwell
In-Reply-To: <CAGHK07BrUmWxbNA3FzYtEqUOji_qn816=dmi_J40S_CKE3kMnA@mail.gmail.com>
On Thu, 2014-11-20 at 14:44 +1100, Jonathan Maxwell wrote:
> > > Prerequisites for this to happen:
> > > 1) The local tcp port range must be exhausted.
> > > 2) A process must have called bind() followed by connect() for all
> > > local ports.
> >
> > How the bind() is done exactly ? How SO_REUSEADDR is used ?
>
> It fails regardless. I tried both with and without for the client and
> server programs.
>
This is the missing part from the programs.
By not using SO_REUSEADDR, programs basically do not allow another
programs to use same port.
> But removing the bind() and just calling connect() from the initial
> program
> then a subsequent connect() from a separate program succeeds. It seems
> that
> this is inconsistent behaviour. The proposed fix makes it behave the
> same for
>
> both cases.
This not consistent behavior is well known and somehow expected by some
applications.
bind() requests the kernel that this socket has a reserved port.
It means the socket can later disconnect from the target, and reconnect
to another, using _same_ source port, or chose to listen() on this port.
That is why kernel is so picky, otherwise the listen() might fail
later...
This is part of BSD socket semantic.
You have to use SO_REUSEADDR on both programs to relax these
constraints.
Your change might break existing programs, really expecting kernel
to behave as requested.
^ permalink raw reply
* Re: [PATCH 1/1] sctp: not send SCTP_PEER_ADDR_CHANGE notifications with failed probe
From: Willy Tarreau @ 2014-11-20 6:14 UTC (permalink / raw)
To: Zhu Yanjun
Cc: netdev, khandelwal.deepak.1987, vyasevich, tuexen, dborkman,
Zhu Yanjun, David S. Miller
In-Reply-To: <1416463480-29036-1-git-send-email-Yanjun.Zhu@windriver.com>
Hi,
On Thu, Nov 20, 2014 at 02:04:40PM +0800, Zhu Yanjun wrote:
> 2.6.x kernels require a similar logic change as commit 2c0d6ac894a
> [sctp: not send SCTP_PEER_ADDR_CHANGE notifications with failed probe]
> introduces for newer kernels.
(...)
Queued for 2.6.32.64, thanks!
Willy
^ permalink raw reply
* [PATCH net V3] virtio-net: validate features during probe
From: Jason Wang @ 2014-11-20 6:10 UTC (permalink / raw)
To: rusty, mst, virtualization, netdev, linux-kernel
We currently trigger BUG when VIRTIO_NET_F_CTRL_VQ
is not set but one of features depending on it is.
That's not a friendly way to report errors to
hypervisors.
Let's check, and fail probe instead.
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
Cc: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
Changes from V2:
- only check the features for ctrl vq (this fix the real bug)
- better error message and simplify API
---
drivers/net/virtio_net.c | 37 +++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index ec2a8b4..a6bcfce 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -1673,6 +1673,40 @@ static const struct attribute_group virtio_net_mrg_rx_group = {
};
#endif
+static bool virtnet_fail_on_feature(struct virtio_device *vdev,
+ unsigned int fbit,
+ const char *fname, const char *dname)
+{
+ if (!virtio_has_feature(vdev, fbit))
+ return false;
+
+ dev_err(&vdev->dev, "Hypervisor bug: advertise feature %s but not %s",
+ fname, dname);
+
+ return true;
+}
+
+#define VIRTNET_FAIL_ON(vdev, fbit, dbit) \
+ virtnet_fail_on_feature(vdev, fbit, #fbit, #dbit)
+
+static bool virtnet_validate_features(struct virtio_device *vdev)
+{
+ if (!virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ) &&
+ (VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_CTRL_RX,
+ VIRTIO_NET_F_CTRL_VQ) ||
+ VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_CTRL_VLAN,
+ VIRTIO_NET_F_CTRL_VQ) ||
+ VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_GUEST_ANNOUNCE,
+ VIRTIO_NET_F_TRL_VQ) ||
+ VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_MQ, VIRTIO_NET_F_CTRL_VQ) ||
+ VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_CTRL_MAC_ADDR,
+ VIRTIO_NET_F_CTRL_VQ))) {
+ return false;
+ }
+
+ return true;
+}
+
static int virtnet_probe(struct virtio_device *vdev)
{
int i, err;
@@ -1680,6 +1714,9 @@ static int virtnet_probe(struct virtio_device *vdev)
struct virtnet_info *vi;
u16 max_queue_pairs;
+ if (!virtnet_validate_features(vdev))
+ return -EINVAL;
+
/* Find if host supports multiqueue virtio_net device */
err = virtio_cread_feature(vdev, VIRTIO_NET_F_MQ,
struct virtio_net_config,
--
1.9.1
^ permalink raw reply related
* [PATCH 1/1] sctp: not send SCTP_PEER_ADDR_CHANGE notifications with failed probe
From: Zhu Yanjun @ 2014-11-20 6:04 UTC (permalink / raw)
To: netdev, w, zyjzyj2000, khandelwal.deepak.1987, vyasevich, tuexen,
dborkman
Cc: Zhu Yanjun, David S. Miller
2.6.x kernels require a similar logic change as commit 2c0d6ac894a
[sctp: not send SCTP_PEER_ADDR_CHANGE notifications with failed probe]
introduces for newer kernels.
Since the transport has always been in state SCTP_UNCONFIRMED, it
therefore wasn't active before and hasn't been used before, and it
always has been, so it is unnecessary to bug the user with a
notification.
Reported-by: Deepak Khandelwal <khandelwal.deepak.1987@gmail.com>
Suggested-by: Vlad Yasevich <vyasevich@gmail.com>
Suggested-by: Michael Tuexen <tuexen@fh-muenster.de>
Suggested-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Zhu Yanjun <Yanjun.Zhu@windriver.com>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Acked-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/sctp/associola.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/net/sctp/associola.c b/net/sctp/associola.c
index 7eed77a..0f63396 100644
--- a/net/sctp/associola.c
+++ b/net/sctp/associola.c
@@ -824,6 +824,7 @@ void sctp_assoc_control_transport(struct sctp_association *asoc,
struct sctp_ulpevent *event;
struct sockaddr_storage addr;
int spc_state = 0;
+ bool ulp_notify = true;
/* Record the transition on the transport. */
switch (command) {
@@ -850,6 +851,7 @@ void sctp_assoc_control_transport(struct sctp_association *asoc,
else {
dst_release(transport->dst);
transport->dst = NULL;
+ ulp_notify = false;
}
spc_state = SCTP_ADDR_UNREACHABLE;
@@ -862,12 +864,14 @@ void sctp_assoc_control_transport(struct sctp_association *asoc,
/* Generate and send a SCTP_PEER_ADDR_CHANGE notification to the
* user.
*/
- memset(&addr, 0, sizeof(struct sockaddr_storage));
- memcpy(&addr, &transport->ipaddr, transport->af_specific->sockaddr_len);
- event = sctp_ulpevent_make_peer_addr_change(asoc, &addr,
+ if (ulp_notify) {
+ memset(&addr, 0, sizeof(struct sockaddr_storage));
+ memcpy(&addr, &transport->ipaddr, transport->af_specific->sockaddr_len);
+ event = sctp_ulpevent_make_peer_addr_change(asoc, &addr,
0, spc_state, error, GFP_ATOMIC);
- if (event)
- sctp_ulpq_tail_event(&asoc->ulpq, event);
+ if (event)
+ sctp_ulpq_tail_event(&asoc->ulpq, event);
+ }
/* Select new active and retran paths. */
--
1.9.1
^ permalink raw reply related
* Re: [PATCH net] virtio-net: validate features during probe
From: Jason Wang @ 2014-11-20 5:28 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: netdev, linux-kernel, virtualization
In-Reply-To: <20141119093901.GB26119@redhat.com>
On 11/19/2014 05:39 PM, Michael S. Tsirkin wrote:
> On Wed, Nov 19, 2014 at 05:33:26PM +0800, Jason Wang wrote:
>> On 11/19/2014 04:59 PM, Michael S. Tsirkin wrote:
>>> On Wed, Nov 19, 2014 at 02:35:39PM +0800, Jason Wang wrote:
>>>> This patch validates feature dependencies during probe and fail the probing
>>>> if a dependency is missed. This fixes the issues of hitting BUG()
>>>> when qemu fails to advertise features correctly. One example is booting
>>>> guest with ctrl_vq=off through qemu.
>>>>
>>>> Cc: Rusty Russell <rusty@rustcorp.com.au>
>>>> Cc: Michael S. Tsirkin <mst@redhat.com>
>>>> Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
>>>> Cc: Wanlong Gao <gaowanlong@cn.fujitsu.com>
>>>> Signed-off-by: Jason Wang <jasowang@redhat.com>
>>>> ---
>>>> drivers/net/virtio_net.c | 93 ++++++++++++++++++++++++++++++++++++++++++++++++
>>>> 1 file changed, 93 insertions(+)
>>>>
>>>> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
>>>> index ec2a8b4..4a0ad46 100644
>>>> --- a/drivers/net/virtio_net.c
>>>> +++ b/drivers/net/virtio_net.c
>>>> @@ -1673,6 +1673,95 @@ static const struct attribute_group virtio_net_mrg_rx_group = {
>>>> };
>>>> #endif
>>>>
>>>> +static int virtnet_validate_features(struct virtio_device *dev,
>>>> + unsigned int *table,
>>>> + int table_size,
>>>> + unsigned int feature)
>>>> +{
>>>> + int i;
>>>> +
>>>> + if (!virtio_has_feature(dev, feature)) {
>>>> + for (i = 0; i < table_size; i++) {
>>>> + unsigned int f = table[i];
>>>> +
>>>> + if (virtio_has_feature(dev, f)) {
>>>> + dev_err(&dev->dev,
>>>> + "buggy hyperviser: feature 0x%x was advertised but its dependency 0x%x was not",
>>> This line's way too long.
>> Yes. (Anyway it pass checkpatch.pl since it forbids quoted string to be
>> split)
[...]
>>>> +
>>>> static int virtnet_probe(struct virtio_device *vdev)
>>>> {
>>>> int i, err;
>>>> @@ -1680,6 +1769,10 @@ static int virtnet_probe(struct virtio_device *vdev)
>>>> struct virtnet_info *vi;
>>>> u16 max_queue_pairs;
>>>>
>>>> + err = virtnet_check_features(vdev);
>>>> + if (err)
>>>> + return -EINVAL;
>>>> +
>>>> /* Find if host supports multiqueue virtio_net device */
>>>> err = virtio_cread_feature(vdev, VIRTIO_NET_F_MQ,
>>>> struct virtio_net_config,
>>> The API seems too complex, and you still had to open-code ECN logic.
>>> Just open-code most of it.
>> Yes, the ECN could be done through the same way as ctrl_vq did.
>>
>> How about move those checking into virtio core by just letting device
>> export its dependency table?
> So far we only have this for net, let's not add
> one-off APIs.
>
>>> You can use a helper macro to output a
>>> friendly message without code duplication.
>>> For example like the below (completely untested)?
>>>
>>>
>>> I would also like to split things: dependencies on
>>> VIRTIO_NET_F_CTRL_VQ might go into this kernel,
>>> since they help fix BUG.
>>>
>>> Others should wait since they don't fix any crashes, and there's a small
>>> chance of a regression for some hypervisor in the field.
>> Probably ok but not sure, since the rest features are all related to
>> csum and offloading, we are in fact depends on network core to fix them.
> Well it does fix them so ... there's no bug, is there?
>
No.
>>> -->
>>>
>>> virtio-net: friendlier handling of misconfigured hypervisors
>>>
>>> We currently trigger BUG when VIRTIO_NET_F_CTRL_VQ
>>> is not set but one of features depending on it is.
>>> That's not a friendly way to report errors to
>>> hypervisors.
>>> Let's check, and fail probe instead.
>>>
>>> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>>>
>>> ---
>>>
>>> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
>>> index 26e1330..7a7d1a3 100644
>>> --- a/drivers/net/virtio_net.c
>>> +++ b/drivers/net/virtio_net.c
>>> @@ -1673,6 +1673,21 @@ static const struct attribute_group virtio_net_mrg_rx_group = {
>>> };
>>> #endif
>>>
>>> +bool __virtnet_fail_on_feature(struct virtio_device *vdev, unsigned int fbit,
>>> + const char *fname)
>>> +{
>>> + if (!virtio_has_feature(vdev, fbit))
>>> + return false;
>>> +
>>> + dev_err(&dev->dev, "missing requirements for feature bit %d: %s\n",
>>> + fbit, fname);
>>> +
>>> + return true;
>>> +}
>>> +
>>> +#define VIRTNET_FAIL_ON(vdev, fbit) \
>>> + __virtnet_fail_on_feature(vdev, fbit, #fbit)
>>> +
>>> static int virtnet_probe(struct virtio_device *vdev)
>>> {
>>> int i, err;
>>> @@ -1680,6 +1695,14 @@ static int virtnet_probe(struct virtio_device *vdev)
>>> struct virtnet_info *vi;
>>> u16 max_queue_pairs;
>>>
>>> + if (!virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_VQ) &&
>>> + (VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_CTRL_RX) ||
>>> + VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_CTRL_VLAN) ||
>>> + VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_GUEST_ANNOUNCE) ||
>>> + VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_MQ) ||
>>> + VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_CTRL_MAC_ADDR)))
>>> + return -EINVAL;
>>> +
>>> /* Find if host supports multiqueue virtio_net device */
>>> err = virtio_cread_feature(vdev, VIRTIO_NET_F_MQ,
>>> struct virtio_net_config,
>>>
>> Patch looks good, but consider we may check more dependencies in the
>> future, may need a helper instead. Or just use this and switch to
>> dependency table in 3.19.
> Pls note this is just pseudo-code - I didn't even compile it.
> If you want something like this merged, go ahead and
> post it, probably addressing Cornelia's request to
> print the dependency too. Maybe:
Ok, will post v3.
>
>>> (VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_CTRL_RX, "ctrl_vq") ||
>>> VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_CTRL_VLAN, "ctrl_vq") ||
>>> VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_GUEST_ANNOUNCE, "ctrl_vq") ||
>>> VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_MQ, "ctrl_vq") ||
>>> VIRTNET_FAIL_ON(vdev, VIRTIO_NET_F_CTRL_MAC_ADDR, "ctrl_vq")))
^ permalink raw reply
* Re: [PATCH net] net/mlx4_en: Add VXLAN ndo calls to the PF net device ops too
From: Or Gerlitz @ 2014-11-20 5:16 UTC (permalink / raw)
To: David Miller; +Cc: netdev, fw, amirv, saeedm
In-Reply-To: <20141119.151155.2119587385505880097.davem@davemloft.net>
On 11/19/2014 10:11 PM, David Miller wrote:
> Applied, -stable material? If so for what releases? In the future, if
> you add an appropriated Fixes: tag I can figure most of this out
> without asking you. Thanks.
Yes, please! let the below commits two swim for a while in 3.18-rc and
later push
them to -stable >= 3.15, got it re the fixes: tag, thanks for the heads-up.
9737c6a net/mlx4_en: Add VXLAN ndo calls to the PF net device ops too
f4a1edd net/mlx4_en: Advertize encapsulation offloads features only when
VXLAN tunnel is set
Or.
^ permalink raw reply
* Re: [PATCH net-next v2] net: sctp: keep owned chunk in destructor_arg instead of skb->cb
From: Vlad Yasevich @ 2014-11-20 3:02 UTC (permalink / raw)
To: Daniel Borkmann, davem; +Cc: linux-sctp, netdev
In-Reply-To: <1416444888-12778-1-git-send-email-dborkman@redhat.com>
On 11/19/2014 07:54 PM, Daniel Borkmann wrote:
> It's just silly to hold the skb destructor argument around inside
> skb->cb[] as we currently do in SCTP.
>
> Nowadays, we're sort of cheating on data accounting in the sense
> that due to commit 4c3a5bdae293 ("sctp: Don't charge for data in
> sndbuf again when transmitting packet"), we orphan the skb already
> in the SCTP output path, i.e. giving back charged data memory, and
> use a different destructor only to make sure the sk doesn't vanish
> on skb destruction time. Thus, cb[] is still valid here as we
> operate within the SCTP layer. (It's generally actually a big
> candidate for future rework, imho.)
>
> However, storing the destructor in the cb[] can easily cause issues
> should an non sctp_packet_set_owner_w()'ed skb ever escape the SCTP
> layer, since cb[] may get overwritten by lower layers and thus can
> corrupt the chunk pointer. There are no such issues at present,
> but lets keep the chunk in destructor_arg, as this is the actual
> purpose for it.
>
> Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Good clean-up.
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
-vlad
> ---
> v1->v2:
> - Only reworded commit message to make it more clear
>
> net/sctp/socket.c | 12 ++++--------
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> index 2120292..85e0b65 100644
> --- a/net/sctp/socket.c
> +++ b/net/sctp/socket.c
> @@ -162,7 +162,7 @@ static inline void sctp_set_owner_w(struct sctp_chunk *chunk)
>
> chunk->skb->destructor = sctp_wfree;
> /* Save the chunk pointer in skb for sctp_wfree to use later. */
> - *((struct sctp_chunk **)(chunk->skb->cb)) = chunk;
> + skb_shinfo(chunk->skb)->destructor_arg = chunk;
>
> asoc->sndbuf_used += SCTP_DATA_SNDSIZE(chunk) +
> sizeof(struct sk_buff) +
> @@ -6870,14 +6870,10 @@ static void sctp_wake_up_waiters(struct sock *sk,
> */
> static void sctp_wfree(struct sk_buff *skb)
> {
> - struct sctp_association *asoc;
> - struct sctp_chunk *chunk;
> - struct sock *sk;
> + struct sctp_chunk *chunk = skb_shinfo(skb)->destructor_arg;
> + struct sctp_association *asoc = chunk->asoc;
> + struct sock *sk = asoc->base.sk;
>
> - /* Get the saved chunk pointer. */
> - chunk = *((struct sctp_chunk **)(skb->cb));
> - asoc = chunk->asoc;
> - sk = asoc->base.sk;
> asoc->sndbuf_used -= SCTP_DATA_SNDSIZE(chunk) +
> sizeof(struct sk_buff) +
> sizeof(struct sctp_chunk);
>
^ permalink raw reply
* Resend - ANNOUNCE: Netdev 0.1 conference
From: Jamal Hadi Salim @ 2014-11-20 2:53 UTC (permalink / raw)
To: netdev; +Cc: info, davem, jaws, rgb
Please forward to all places you think are relevant.
[original email i sent had the wrong contact info at the
bottom should be: info@netdev01.info]
Netdev 0.1 (year 0, conference 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 focus.
If you are using Linux as a boot system for proprietary networking,
then this conference _may not be for you_.
The netdev conference this year is structured to be 50/50
by-invitation and talk submission. We are making sure that we
reach out to speakers who have interesting relevant topics because
we recognize most of these folks would typically not be submitting
papers to a conference. The invitation will be made by the technical
committee to the individual speakers both for paper and tutorial
sessions.
The call for papers is for the 50% submission portion of the
conference for both paper submission as well as tutorials.
We *highly discourage* submission of recycled talks.
Current topics include
- wireless
- performance analysis and improvement
- networking hardware and offload
- netfilter
- traffic control
- different networking layers (L2/3, etc)
- internet of things
- security
- additional topics can be suggested
We encourage submission of papers and tutorials. Unlike other
conferences, we are going to try and accommodate as many submissions
as possible - but please stay within the relevant topic focus and
tie to Linux networking to make it easier for the technical committee
to provide quick feedback. In order to give a talk you must be
registered. If your proposal is accepted you will not be charged
a conference fee or your conference fee will be refunded to you
when your talk gets accepted.
We will be posting more updates on how to submit in the near future.
We expect about 3-4 parallel tracks both during tutorials and main
talks. Tutorials will be on the first day and talks on subsequent days.
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 flashy
openings. There will just be a pure feed of Linux networking.
netdev 0.1 will be held back to back with netconf 2015, the
by-invite Linux kernel networking workshop
(http://vger.kernel.org/netconf2015.html).
So gurus of all sorts will be there mingling and giving talks.
While there will be heavy Linux kernel influence we expect a lot
of user space presence as well.
Location:
---------
Downtown Ottawa, Canada. Exact location to be announced.
www.netdev01.org
Important Dates:
----------------
November 26, 2014 Call for Papers opens
December 10, 2014 Registration opens
January 10, 2015 Call for sessions deadline
January 20, 2015 Conference schedule announced
February 14-17, 2015 Conference days
Please register as soon as registration opens up on December 10.
Registering helps us plan properly for numbers of attendees,
ensuring venue sizes and supplies are appropriate without
wasting resources.
contact:
--------
info@netdev01.info
^ permalink raw reply
* ANNOUNCE: Netdev 0.1 conference
From: Jamal Hadi Salim @ 2014-11-20 2:47 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: info, David Miller, Stephen Jaworski, Richard Guy Briggs
Please forward to all places you think are relevant.
Netdev 0.1 (year 0, conference 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 focus.
If you are using Linux as a boot system for proprietary networking,
then this conference _may not be for you_.
The netdev conference this year is structured to be 50/50
by-invitation and talk submission. We are making sure that we
reach out to speakers who have interesting relevant topics because
we recognize most of these folks would typically not be submitting
papers to a conference. The invitation will be made by the technical
committee to the individual speakers both for paper and tutorial
sessions.
The call for papers is for the 50% submission portion of the
conference for both paper submission as well as tutorials.
We *highly discourage* submission of recycled talks.
Current topics include
- wireless
- performance analysis and improvement
- networking hardware and offload
- netfilter
- traffic control
- different networking layers (L2/3, etc)
- internet of things
- security
- additional topics can be suggested
We encourage submission of papers and tutorials. Unlike other
conferences, we are going to try and accommodate as many submissions
as possible - but please stay within the relevant topic focus and
tie to Linux networking to make it easier for the technical committee
to provide quick feedback. In order to give a talk you must be
registered. If your proposal is accepted you will not be charged
a conference fee or your conference fee will be refunded to you
when your talk gets accepted.
We will be posting more updates on how to submit in the near future.
We expect about 3-4 parallel tracks both during tutorials and main
talks. Tutorials will be on the first day and talks on subsequent days.
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 flashy
openings. There will just be a pure feed of Linux networking.
netdev 0.1 will be held back to back with netconf 2015, the
by-invite Linux kernel networking workshop
(http://vger.kernel.org/netconf2015.html).
So gurus of all sorts will be there mingling and giving talks.
While there will be heavy Linux kernel influence we expect a lot
of user space presence as well.
Location:
---------
Downtown Ottawa, Canada. Exact location to be announced.
www.netdev01.org
Important Dates:
----------------
November 26, 2014 Call for Papers opens
December 10, 2014 Registration opens
January 10, 2015 Call for sessions deadline
January 20, 2015 Conference schedule announced
February 14-17, 2015 Conference days
Please register as soon as registration opens up on December 10.
Registering helps us plan properly for numbers of attendees,
ensuring venue sizes and supplies are appropriate without
wasting resources.
contact:
--------
info@netdev.info
^ permalink raw reply
* [PATCH net-next v3 2/2] r8152: adjust rtl_start_rx
From: Hayes Wang @ 2014-11-20 2:29 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
In-Reply-To: <1394712342-15778-98-Taiwan-albertk@realtek.com>
If there is a error for r8152_submit_rx(), add the remaining rx
buffers to the list. Then the remaining rx buffers could be
submitted later.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/usb/r8152.c | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 3b89229..4a9ece0 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -2001,6 +2001,25 @@ static int rtl_start_rx(struct r8152 *tp)
break;
}
+ if (ret && ++i < RTL8152_MAX_RX) {
+ struct list_head rx_queue;
+ unsigned long flags;
+
+ INIT_LIST_HEAD(&rx_queue);
+
+ do {
+ struct rx_agg *agg = &tp->rx_info[i++];
+ struct urb *urb = agg->urb;
+
+ urb->actual_length = 0;
+ list_add_tail(&agg->list, &rx_queue);
+ } while (i < RTL8152_MAX_RX);
+
+ spin_lock_irqsave(&tp->rx_lock, flags);
+ list_splice_tail(&rx_queue, &tp->rx_done);
+ spin_unlock_irqrestore(&tp->rx_lock, flags);
+ }
+
return ret;
}
--
1.9.3
^ permalink raw reply related
* [PATCH net-next v3 1/2] r8152: adjust r8152_submit_rx
From: Hayes Wang @ 2014-11-20 2:29 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
In-Reply-To: <1394712342-15778-98-Taiwan-albertk@realtek.com>
The behavior of handling the returned status from r8152_submit_rx()
is almost same, so let r8152_submit_rx() deal with the error
directly. This could avoid the duplicate code.
Signed-off-by: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/usb/r8152.c | 40 ++++++++++++++++++++--------------------
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 0a30fd3..3b89229 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1032,7 +1032,6 @@ static void read_bulk_callback(struct urb *urb)
int status = urb->status;
struct rx_agg *agg;
struct r8152 *tp;
- int result;
agg = urb->context;
if (!agg)
@@ -1083,16 +1082,7 @@ static void read_bulk_callback(struct urb *urb)
break;
}
- result = r8152_submit_rx(tp, agg, GFP_ATOMIC);
- if (result == -ENODEV) {
- set_bit(RTL8152_UNPLUG, &tp->flags);
- netif_device_detach(tp->netdev);
- } else if (result) {
- spin_lock(&tp->rx_lock);
- list_add_tail(&agg->list, &tp->rx_done);
- spin_unlock(&tp->rx_lock);
- tasklet_schedule(&tp->tl);
- }
+ r8152_submit_rx(tp, agg, GFP_ATOMIC);
}
static void write_bulk_callback(struct urb *urb)
@@ -1680,7 +1670,6 @@ static void rx_bottom(struct r8152 *tp)
int len_used = 0;
struct urb *urb;
u8 *rx_data;
- int ret;
list_del_init(cursor);
@@ -1733,13 +1722,7 @@ find_next_rx:
}
submit:
- ret = r8152_submit_rx(tp, agg, GFP_ATOMIC);
- if (ret && ret != -ENODEV) {
- spin_lock_irqsave(&tp->rx_lock, flags);
- list_add_tail(&agg->list, &tp->rx_done);
- spin_unlock_irqrestore(&tp->rx_lock, flags);
- tasklet_schedule(&tp->tl);
- }
+ r8152_submit_rx(tp, agg, GFP_ATOMIC);
}
}
@@ -1806,11 +1789,28 @@ static void bottom_half(unsigned long data)
static
int r8152_submit_rx(struct r8152 *tp, struct rx_agg *agg, gfp_t mem_flags)
{
+ int ret;
+
usb_fill_bulk_urb(agg->urb, tp->udev, usb_rcvbulkpipe(tp->udev, 1),
agg->head, agg_buf_sz,
(usb_complete_t)read_bulk_callback, agg);
- return usb_submit_urb(agg->urb, mem_flags);
+ ret = usb_submit_urb(agg->urb, mem_flags);
+ if (ret == -ENODEV) {
+ set_bit(RTL8152_UNPLUG, &tp->flags);
+ netif_device_detach(tp->netdev);
+ } else if (ret) {
+ struct urb *urb = agg->urb;
+ unsigned long flags;
+
+ urb->actual_length = 0;
+ spin_lock_irqsave(&tp->rx_lock, flags);
+ list_add_tail(&agg->list, &tp->rx_done);
+ spin_unlock_irqrestore(&tp->rx_lock, flags);
+ tasklet_schedule(&tp->tl);
+ }
+
+ return ret;
}
static void rtl_drop_queued_tx(struct r8152 *tp)
--
1.9.3
^ permalink raw reply related
* [PATCH net-next v3 0/2] r8152: adjust rx functions
From: Hayes Wang @ 2014-11-20 2:29 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, linux-usb, Hayes Wang
In-Reply-To: <1394712342-15778-88-Taiwan-albertk@realtek.com>
v3:
For patch #1, remove unnecessary initialization for ret and
unnecessary blank line in r8152_submit_rx().
v2:
For patch #1, set actual_length to 0 before adding the rx to the
list, when a error occurs.
For patch #2, change the flow. Stop submitting the rx if a error
occurs, and add the remaining rx to the list for submitting later.
v1:
Adjust some flows and codes which are relative to r8152_submit_rx()
and rtl_start_rx().
Hayes Wang (2):
r8152: adjust r8152_submit_rx
r8152: adjust rtl_start_rx
drivers/net/usb/r8152.c | 60 ++++++++++++++++++++++++++++++++-----------------
1 file changed, 40 insertions(+), 20 deletions(-)
--
1.9.3
^ permalink raw reply
* Re: [PATCH net-next] net: use skb_get_hash_raw instead of skb_get_hash in set_rps_cpu
From: David Miller @ 2014-11-20 1:57 UTC (permalink / raw)
To: therbert; +Cc: _govind, netdev
In-Reply-To: <CA+mtBx9K61KmguzQBWNbnmesCvWtzh_SjjbjedkgxN6p4Oay4Q@mail.gmail.com>
From: Tom Herbert <therbert@google.com>
Date: Wed, 19 Nov 2014 16:51:40 -0800
> On Wed, Nov 19, 2014 at 4:16 PM, David Miller <davem@davemloft.net> wrote:
>> From: Govindarajulu Varadarajan <_govind@gmx.com>
>> Date: Wed, 19 Nov 2014 15:30:44 +0530
>>
>>> In set_rps_cpu, we call skb_get_hash to get the hash of skb. The caller
>>> get_rps_cpu has already determined the hash of skb by calling skb_get_hash.
>>>
>>> Since get_rps_cpu is the only caller of set_rps_cpu, we can use skb_get_hash_raw
>>>
>>> Signed-off-by: Govindarajulu Varadarajan <_govind@gmx.com>
>>
>> Tom, please review. And if you agree with this change, you'll need to
>> be spinning your flow_id change relative to this I guess since it overlaps.
>>
> We should probably pass hash as an argument in set_rps_cpu. It's only
> called from once place and the rflow is specifically chosen based on
> hash computed by caller-- don't want any ambiguity there.
Yep, that sounds a lot less error prone.
^ permalink raw reply
* Re: [patch net-next v4 1/9] openvswitch: actions: use skb_postpull_rcsum when possible
From: Simon Horman @ 2014-11-20 1:52 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, jhs, pshelar, therbert, edumazet, willemb,
dborkman, mst, fw, Paul.Durrant, tgraf, cwang
In-Reply-To: <1416402303-25341-2-git-send-email-jiri@resnulli.us>
On Wed, Nov 19, 2014 at 02:04:55PM +0100, Jiri Pirko wrote:
> Replace duplicated code by calling skb_postpull_rcsum
>
> Suggested-by: Eric Dumazet <eric.dumazet@gmail.com>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
> Acked-by: Pravin B Shelar <pshelar@nicira.com>
I believe this may have originally been my handiwork:
Acked-by: Simon Horman <simon.horman@netronome.com>
> ---
> net/openvswitch/actions.c | 9 ++-------
> 1 file changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
> index 394efa6..749a301 100644
> --- a/net/openvswitch/actions.c
> +++ b/net/openvswitch/actions.c
> @@ -175,10 +175,7 @@ static int pop_mpls(struct sk_buff *skb, struct sw_flow_key *key,
> if (unlikely(err))
> return err;
>
> - if (skb->ip_summed == CHECKSUM_COMPLETE)
> - skb->csum = csum_sub(skb->csum,
> - csum_partial(skb_mpls_header(skb),
> - MPLS_HLEN, 0));
> + skb_postpull_rcsum(skb, skb_mpls_header(skb), MPLS_HLEN);
>
> memmove(skb_mac_header(skb) + MPLS_HLEN, skb_mac_header(skb),
> skb->mac_len);
> @@ -230,9 +227,7 @@ static int __pop_vlan_tci(struct sk_buff *skb, __be16 *current_tci)
> if (unlikely(err))
> return err;
>
> - if (skb->ip_summed == CHECKSUM_COMPLETE)
> - skb->csum = csum_sub(skb->csum, csum_partial(skb->data
> - + (2 * ETH_ALEN), VLAN_HLEN, 0));
> + skb_postpull_rcsum(skb, skb->data + (2 * ETH_ALEN), VLAN_HLEN);
>
> vhdr = (struct vlan_hdr *)(skb->data + ETH_HLEN);
> *current_tci = vhdr->h_vlan_TCI;
> --
> 1.9.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH 1/1] netfilter: Deletion of unnecessary checks before two function calls
From: Simon Horman @ 2014-11-20 1:13 UTC (permalink / raw)
To: Julian Anastasov
Cc: SF Markus Elfring, David S. Miller, Jozsef Kadlecsik,
Pablo Neira Ayuso, Patrick McHardy, Wensong Zhang, netdev,
lvs-devel, netfilter-devel, coreteam, LKML, kernel-janitors,
Coccinelle
In-Reply-To: <alpine.LFD.2.11.1411200024280.6497@ja.home.ssi.bg>
On Thu, Nov 20, 2014 at 12:26:56AM +0200, Julian Anastasov wrote:
>
> Hello,
>
> On Tue, 18 Nov 2014, SF Markus Elfring wrote:
>
> > From: Markus Elfring <elfring@users.sourceforge.net>
> > Date: Tue, 18 Nov 2014 20:37:05 +0100
> >
> > The functions free_percpu() and module_put() test whether their argument
> > is NULL and then return immediately. Thus the test around the call is
> > not needed.
> >
> > This issue was detected by using the Coccinelle software.
> >
> > Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
>
> Pablo, the IPVS parts look ok to me,
>
> Acked-by: Julian Anastasov <ja@ssi.bg>
Acked-by: Simon Horman <horms@verge.net.au>
>
> > ---
> > net/netfilter/ipvs/ip_vs_ctl.c | 3 +--
> > net/netfilter/ipvs/ip_vs_pe.c | 3 +--
> > net/netfilter/ipvs/ip_vs_sched.c | 3 +--
> > net/netfilter/ipvs/ip_vs_sync.c | 3 +--
> > net/netfilter/nf_tables_api.c | 3 +--
> > 5 files changed, 5 insertions(+), 10 deletions(-)
> >
> > diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
> > index fd3f444..7c5e40a 100644
> > --- a/net/netfilter/ipvs/ip_vs_ctl.c
> > +++ b/net/netfilter/ipvs/ip_vs_ctl.c
> > @@ -465,8 +465,7 @@ __ip_vs_bind_svc(struct ip_vs_dest *dest, struct ip_vs_service *svc)
> >
> > static void ip_vs_service_free(struct ip_vs_service *svc)
> > {
> > - if (svc->stats.cpustats)
> > - free_percpu(svc->stats.cpustats);
> > + free_percpu(svc->stats.cpustats);
> > kfree(svc);
> > }
> >
> > diff --git a/net/netfilter/ipvs/ip_vs_pe.c b/net/netfilter/ipvs/ip_vs_pe.c
> > index 1a82b29..0df17ca 100644
> > --- a/net/netfilter/ipvs/ip_vs_pe.c
> > +++ b/net/netfilter/ipvs/ip_vs_pe.c
> > @@ -37,8 +37,7 @@ struct ip_vs_pe *__ip_vs_pe_getbyname(const char *pe_name)
> > rcu_read_unlock();
> > return pe;
> > }
> > - if (pe->module)
> > - module_put(pe->module);
> > + module_put(pe->module);
> > }
> > rcu_read_unlock();
> >
> > diff --git a/net/netfilter/ipvs/ip_vs_sched.c b/net/netfilter/ipvs/ip_vs_sched.c
> > index 4dbcda6..199760c 100644
> > --- a/net/netfilter/ipvs/ip_vs_sched.c
> > +++ b/net/netfilter/ipvs/ip_vs_sched.c
> > @@ -104,8 +104,7 @@ static struct ip_vs_scheduler *ip_vs_sched_getbyname(const char *sched_name)
> > mutex_unlock(&ip_vs_sched_mutex);
> > return sched;
> > }
> > - if (sched->module)
> > - module_put(sched->module);
> > + module_put(sched->module);
> > }
> >
> > mutex_unlock(&ip_vs_sched_mutex);
> > diff --git a/net/netfilter/ipvs/ip_vs_sync.c b/net/netfilter/ipvs/ip_vs_sync.c
> > index eadffb2..cafe28d 100644
> > --- a/net/netfilter/ipvs/ip_vs_sync.c
> > +++ b/net/netfilter/ipvs/ip_vs_sync.c
> > @@ -820,8 +820,7 @@ ip_vs_conn_fill_param_sync(struct net *net, int af, union ip_vs_sync_conn *sc,
> >
> > p->pe_data = kmemdup(pe_data, pe_data_len, GFP_ATOMIC);
> > if (!p->pe_data) {
> > - if (p->pe->module)
> > - module_put(p->pe->module);
> > + module_put(p->pe->module);
> > return -ENOMEM;
> > }
> > p->pe_data_len = pe_data_len;
> > diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c
> > index deeb95f..b115f54 100644
> > --- a/net/netfilter/nf_tables_api.c
> > +++ b/net/netfilter/nf_tables_api.c
> > @@ -3472,8 +3472,7 @@ static int nf_tables_abort(struct sk_buff *skb)
> > break;
> > case NFT_MSG_NEWCHAIN:
> > if (nft_trans_chain_update(trans)) {
> > - if (nft_trans_chain_stats(trans))
> > - free_percpu(nft_trans_chain_stats(trans));
> > + free_percpu(nft_trans_chain_stats(trans));
> >
> > nft_trans_destroy(trans);
> > } else {
> > --
> > 2.1.3
>
> Regards
>
> --
> Julian Anastasov <ja@ssi.bg>
>
^ permalink raw reply
* Re: [PATCH RFC] net: Pass full skb hash to ndo_rx_flow_steer
From: Tom Herbert @ 2014-11-20 1:04 UTC (permalink / raw)
To: Andy Lutomirski; +Cc: Ben Hutchings, Network Development
In-Reply-To: <CALCETrU9QXUy5EK5JjmqXo50ZqdHRRbsz3eJzLuCJgadN2jPHw@mail.gmail.com>
On Wed, Nov 19, 2014 at 4:21 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Tue, Nov 18, 2014 at 8:08 PM, Tom Herbert <therbert@google.com> wrote:
>> Currently, for aRFS the index into the flow table is passed to
>> ndo_rx_flow_steer as the flow ID of a connection. This is the skb->hash
>> & the table mask. It looks like the backend can accept the full
>> skb->hash as the flow ID which should reduce the number of collisions
>> in the hardware tables.
>>
>> This patch provides the skb->hash to the driver for flow steering.
>> Expiration of HW steered flows was also updated.
>>
>> With a hash collision in RFS, ndo_rx_flow_steer will continue to be
>> called with different CPUs, but now with different flow_ids. If this
>> is still too much device interaction, then it might make sense for the
>> driver to do its own lookup in its structure to see if a matching
>> filter is already installed for a given flow_id, an if it is just
>> refresh a timestamp to avoid expiration (based on looking at sfc
>> driver).
>>
>> I don't currently have any HW to test this, if someone could try this
>> on hardware with aRFS and provide feedback that would be appreciated.
>>
>> Signed-off-by: Tom Herbert <therbert@google.com>
>> ---
>> net/core/dev.c | 7 ++++---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/net/core/dev.c b/net/core/dev.c
>> index 1ab168e..cb1e06d 100644
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -3057,7 +3057,8 @@ set_rps_cpu(struct net_device *dev, struct sk_buff *skb,
>> goto out;
>> flow_id = skb_get_hash(skb) & flow_table->mask;
>> rc = dev->netdev_ops->ndo_rx_flow_steer(dev, skb,
>> - rxq_index, flow_id);
>> + rxq_index,
>> + skb_get_hash(skb));
>
> Can gcc CSE this? Not that it matters that much.
>
>> if (rc < 0)
>> goto out;
>> old_rflow = rflow;
>> @@ -3195,8 +3196,8 @@ bool rps_may_expire_flow(struct net_device *dev, u16 rxq_index,
>>
>> rcu_read_lock();
>> flow_table = rcu_dereference(rxqueue->rps_flow_table);
>> - if (flow_table && flow_id <= flow_table->mask) {
>> - rflow = &flow_table->flows[flow_id];
>> + if (flow_table) {
>> + rflow = &flow_table->flows[flow_id & flow_table->mask];
>
> I think this is nicer, but why will it help? If there's a collision
> in the low bits of the hash, we'll still think that the flow is
> expired.
>
> Is there a real LRU-ish hash table that could be subbed in easily?
I think this does exist in sfc, or at least could potentially be
updated to do it. When a filter is being inserted, there is a lookup
on the spec to see if a matching filter already exists. If it is
found, -EBUSY is returned. I "think" that instead of returning -EBUSY,
the filter index could be returned and a timestamp in the soft data
structure could be refreshed. In the driver expiration code, the
timestamp could be checked before deciding to call
rps_may_expire_flow. In the case of a collision in the RPS flow table,
ndo_rx_flow_steer would be alternately called for the flows which
should continuously refresh the timestamps of the filters for each
flow. This should keep both flow filters active in the device, without
needing to whack the device for each call to ndo_rx_flow_steer.
> There ought to be a data structure that's barely more complicated than
> this kind of hash table but that gives much better behavior when the
> number of flows is smaller than the table size.
>
> --Andy
>
>> cpu = ACCESS_ONCE(rflow->cpu);
>> if (rflow->filter == filter_id && cpu != RPS_NO_CPU &&
>> ((int)(per_cpu(softnet_data, cpu).input_queue_head -
>> --
>> 2.1.0.rc2.206.gedb03e5
>>
>
>
>
> --
> Andy Lutomirski
> AMA Capital Management, LLC
^ permalink raw reply
* [PATCH net-next v2] net: sctp: keep owned chunk in destructor_arg instead of skb->cb
From: Daniel Borkmann @ 2014-11-20 0:54 UTC (permalink / raw)
To: davem; +Cc: linux-sctp, netdev
It's just silly to hold the skb destructor argument around inside
skb->cb[] as we currently do in SCTP.
Nowadays, we're sort of cheating on data accounting in the sense
that due to commit 4c3a5bdae293 ("sctp: Don't charge for data in
sndbuf again when transmitting packet"), we orphan the skb already
in the SCTP output path, i.e. giving back charged data memory, and
use a different destructor only to make sure the sk doesn't vanish
on skb destruction time. Thus, cb[] is still valid here as we
operate within the SCTP layer. (It's generally actually a big
candidate for future rework, imho.)
However, storing the destructor in the cb[] can easily cause issues
should an non sctp_packet_set_owner_w()'ed skb ever escape the SCTP
layer, since cb[] may get overwritten by lower layers and thus can
corrupt the chunk pointer. There are no such issues at present,
but lets keep the chunk in destructor_arg, as this is the actual
purpose for it.
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
---
v1->v2:
- Only reworded commit message to make it more clear
net/sctp/socket.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 2120292..85e0b65 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -162,7 +162,7 @@ static inline void sctp_set_owner_w(struct sctp_chunk *chunk)
chunk->skb->destructor = sctp_wfree;
/* Save the chunk pointer in skb for sctp_wfree to use later. */
- *((struct sctp_chunk **)(chunk->skb->cb)) = chunk;
+ skb_shinfo(chunk->skb)->destructor_arg = chunk;
asoc->sndbuf_used += SCTP_DATA_SNDSIZE(chunk) +
sizeof(struct sk_buff) +
@@ -6870,14 +6870,10 @@ static void sctp_wake_up_waiters(struct sock *sk,
*/
static void sctp_wfree(struct sk_buff *skb)
{
- struct sctp_association *asoc;
- struct sctp_chunk *chunk;
- struct sock *sk;
+ struct sctp_chunk *chunk = skb_shinfo(skb)->destructor_arg;
+ struct sctp_association *asoc = chunk->asoc;
+ struct sock *sk = asoc->base.sk;
- /* Get the saved chunk pointer. */
- chunk = *((struct sctp_chunk **)(skb->cb));
- asoc = chunk->asoc;
- sk = asoc->base.sk;
asoc->sndbuf_used -= SCTP_DATA_SNDSIZE(chunk) +
sizeof(struct sk_buff) +
sizeof(struct sctp_chunk);
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH net-next] net: use skb_get_hash_raw instead of skb_get_hash in set_rps_cpu
From: Tom Herbert @ 2014-11-20 0:51 UTC (permalink / raw)
To: David Miller; +Cc: _govind, Linux Netdev List
In-Reply-To: <20141119.191610.1447608233879904907.davem@davemloft.net>
On Wed, Nov 19, 2014 at 4:16 PM, David Miller <davem@davemloft.net> wrote:
> From: Govindarajulu Varadarajan <_govind@gmx.com>
> Date: Wed, 19 Nov 2014 15:30:44 +0530
>
>> In set_rps_cpu, we call skb_get_hash to get the hash of skb. The caller
>> get_rps_cpu has already determined the hash of skb by calling skb_get_hash.
>>
>> Since get_rps_cpu is the only caller of set_rps_cpu, we can use skb_get_hash_raw
>>
>> Signed-off-by: Govindarajulu Varadarajan <_govind@gmx.com>
>
> Tom, please review. And if you agree with this change, you'll need to
> be spinning your flow_id change relative to this I guess since it overlaps.
>
We should probably pass hash as an argument in set_rps_cpu. It's only
called from once place and the rflow is specifically chosen based on
hash computed by caller-- don't want any ambiguity there.
>> ---
>> net/core/dev.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/net/core/dev.c b/net/core/dev.c
>> index 1ab168e..b4ad4d1 100644
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -3055,7 +3055,7 @@ set_rps_cpu(struct net_device *dev, struct sk_buff *skb,
>> flow_table = rcu_dereference(rxqueue->rps_flow_table);
>> if (!flow_table)
>> goto out;
>> - flow_id = skb_get_hash(skb) & flow_table->mask;
>> + flow_id = skb_get_hash_raw(skb) & flow_table->mask;
>> rc = dev->netdev_ops->ndo_rx_flow_steer(dev, skb,
>> rxq_index, flow_id);
>> if (rc < 0)
>> --
>> 2.1.0
>>
^ permalink raw reply
* Re: [PATCHv10 ovs 12/15] datapath: Add support for unique flow identifiers.
From: Pravin Shelar @ 2014-11-20 0:39 UTC (permalink / raw)
To: Joe Stringer; +Cc: dev@openvswitch.org, netdev
In-Reply-To: <201411191620.32217.joestringer@nicira.com>
On Wed, Nov 19, 2014 at 4:20 PM, Joe Stringer <joestringer@nicira.com> wrote:
> On Wednesday, November 19, 2014 15:34:24 Pravin Shelar wrote:
>> On Thu, Nov 13, 2014 at 11:17 AM, Joe Stringer <joestringer@nicira.com>
> wrote:
>> > @@ -684,33 +691,43 @@ static size_t ovs_flow_cmd_msg_size(const struct
>> > sw_flow_actions *acts)
>> >
>> > /* Called with ovs_mutex or RCU read lock. */
>> > static int ovs_flow_cmd_fill_match(const struct sw_flow *flow,
>> >
>> > - struct sk_buff *skb)
>> > + struct sk_buff *skb, u32 ufid_flags)
>> >
>> > {
>> >
>> > struct nlattr *nla;
>> > int err;
>> >
>> > - /* Fill flow key. */
>> > - nla = nla_nest_start(skb, OVS_FLOW_ATTR_KEY);
>> > - if (!nla)
>> > - return -EMSGSIZE;
>> > -
>> > - err = ovs_nla_put_flow(&flow->unmasked_key, &flow->unmasked_key,
>> > skb, - false);
>> > - if (err)
>> > - return err;
>> > -
>> > - nla_nest_end(skb, nla);
>> > + /* Fill flow key. If userspace didn't specify a UFID, then ignore
>> > the + * OMIT_KEY flag. */
>> > + if (!(ufid_flags & OVS_UFID_F_OMIT_KEY) ||
>> > + !flow->index_by_ufid) {
>>
>> I am not sure about this check, userspace needs to send atleast ufid
>> or the unmasked key as id for flow. otherwise we shld flag error. Here
>> we can serialize flow->key.
>> There could be another function which takes care of flow-id
>> serialization where we serialize use ufid or unmasked key as flow id.
>> Lets group ufid and unmasked key together rather than masked key and
>> unmasked key which are not related.
>
> Right, at flow setup time the flow key is always required, but the UFID is
> optional. For most other cases, one of the two most be specified. For flow dump,
> neither is required from userspace, but OMIT_KEY flag may be raised. That's the
> particular case that this logic is trying to catch (dump all flows, including
> those that were set up without UFID - in which case the OMIT_KEY flag doesn't
> make sense, so treat the flag like a request rather than a command).
>
How do you handle overlapping flows without the flow id in dump operation?
> Happy to split the key/identifier out from the mask.
>
>> > @@ -740,6 +757,32 @@ static int ovs_flow_cmd_fill_stats(const struct
>> > sw_flow *flow,
>> >
>> > }
>> >
>> > /* Called with ovs_mutex or RCU read lock. */
>> >
>> > +static int ovs_flow_cmd_fill_ufid(const struct sw_flow *flow,
>> > + struct sk_buff *skb)
>> > +{
>> > + struct nlattr *start;
>> > + const struct sw_flow_id *sfid;
>> > +
>> > + if (!flow->index_by_ufid)
>> > + return 0;
>> > +
>> > + sfid = &flow->index.ufid;
>> > + start = nla_nest_start(skb, OVS_FLOW_ATTR_UFID);
>> > + if (start) {
>> > + int err;
>> > +
>> > + err = nla_put(skb, OVS_UFID_ATTR_ID, sfid->ufid_len,
>> > + sfid->ufid);
>> > + if (err)
>> > + return err;
>> > + nla_nest_end(skb, start);
>> > + } else
>> > + return -EMSGSIZE;
>> > +
>> > + return 0;
>> > +}
>> > +
>>
>> Can you change this function according to comments above?
>
> OK.
>
>> > @@ -795,18 +838,24 @@ static int ovs_flow_cmd_fill_info(const struct
>> > sw_flow *flow, int dp_ifindex,
>> >
>> > ovs_header->dp_ifindex = dp_ifindex;
>> >
>> > - err = ovs_flow_cmd_fill_match(flow, skb);
>> > + err = ovs_flow_cmd_fill_match(flow, skb, ufid_flags);
>> >
>> > if (err)
>> >
>> > goto error;
>> >
>> > - err = ovs_flow_cmd_fill_stats(flow, skb);
>> > + err = ovs_flow_cmd_fill_ufid(flow, skb);
>> >
>> > if (err)
>> >
>> > goto error;
>>
>> Flow ID should go first in the netlink msg.
>
> OK.
>
>> > @@ -915,8 +980,9 @@ static int ovs_flow_cmd_new(struct sk_buff *skb,
>> > struct genl_info *info)
>> >
>> > error = -ENODEV;
>> > goto err_unlock_ovs;
>> >
>> > }
>> >
>> > +
>> >
>> > /* Check if this is a duplicate flow */
>> >
>> > - flow = ovs_flow_tbl_lookup(&dp->table, &new_flow->unmasked_key);
>> > + flow = ovs_flow_tbl_lookup(&dp->table, &new_flow->key);
>>
>> Need to check for ufid table to find duplicate ufid entry here.
>
> OK.
>
>> > diff --git a/datapath/flow.h b/datapath/flow.h
>> > index 2bbf789..736e0eb 100644
>> > --- a/datapath/flow.h
>> > +++ b/datapath/flow.h
>> > @@ -196,6 +196,13 @@ struct sw_flow_match {
>> >
>> > struct sw_flow_mask *mask;
>> >
>> > };
>> >
>> > +struct sw_flow_id {
>> > + struct hlist_node node[2];
>> > + u32 hash;
>> > + u8 *ufid;
>> > + u8 ufid_len;
>> > +};
>> > +
>>
>> Lets make ufid array of size 256, we can reject any key greater than
>> this. current patch does not support key greater than 256 anyways.
>
> Ok, that sounds reasonable.
>
>> > struct sw_flow_actions {
>> >
>> > struct rcu_head rcu;
>> > u32 actions_len;
>> >
>> > @@ -212,13 +219,20 @@ struct flow_stats {
>> >
>> > struct sw_flow {
>> >
>> > struct rcu_head rcu;
>> >
>> > - struct hlist_node hash_node[2];
>> > - u32 hash;
>> > + struct {
>> > + struct hlist_node node[2];
>> > + u32 hash;
>> > + } flow_hash;
>>
>> This change does not look related to this work.
>
> Right, this is unnecessary leftover from earlier iteration.
>
>
>> > int stats_last_writer; /* NUMA-node id of the last
>> > writer on
>> >
>> > * 'stats[0]'.
>> > */
>> >
>> > struct sw_flow_key key;
>> >
>> > - struct sw_flow_key unmasked_key;
>> > + bool index_by_ufid; /* Which of the below that
>> > userspace + uses to index this
>> > flow. */ + union {
>> > + struct sw_flow_key unmasked_key;
>> > + struct sw_flow_id ufid;
>> > + } index;
>>
>> Rather than storing ufid or unmasked key inside struct flow we can
>> keep pointer to these objects, that will save some memory.
>
> OK. Do you still care about the union being there?
>
Lets keep both pointer so that we can get rid of the index_by_fid flag.
>> > @@ -818,31 +914,65 @@ static int flow_mask_insert(struct flow_table *tbl,
>> > struct sw_flow *flow,
>> >
>> > int ovs_flow_tbl_insert(struct flow_table *table, struct sw_flow *flow,
>> >
>> > const struct sw_flow_mask *mask)
>> >
>> > {
>> >
>> > - struct table_instance *new_ti = NULL;
>> > - struct table_instance *ti;
>> > + struct table_instance *new_ti = NULL, *new_ufid_ti = NULL;
>> > + struct table_instance *ti, *ufid_ti = NULL;
>> >
>> > int err;
>> >
>> > err = flow_mask_insert(table, flow, mask);
>> > if (err)
>> >
>> > return err;
>> >
>> > - flow->hash = flow_hash(&flow->key, flow->mask->range.start,
>> > - flow->mask->range.end);
>> > + flow->flow_hash.hash = flow_hash(&flow->key,
>> > flow->mask->range.start, +
>> > flow->mask->range.end);
>> >
>> > ti = ovsl_dereference(table->ti);
>> > table_instance_insert(ti, flow);
>> > table->count++;
>> >
>> > + if (flow->index_by_ufid) {
>> > + flow->index.ufid.hash = ufid_hash(&flow->index.ufid);
>> > + ufid_ti = ovsl_dereference(table->ufid_ti);
>> > + ufid_table_instance_insert(ufid_ti, flow);
>> > + table->ufid_count++;
>> > + }
>> >
>> > /* Expand table, if necessary, to make room. */
>> > if (table->count > ti->n_buckets)
>> >
>> > - new_ti = table_instance_expand(ti);
>> > + new_ti = flow_table_expand(ti, false);
>> >
>> > else if (time_after(jiffies, table->last_rehash +
>> > REHASH_INTERVAL))
>> >
>> > - new_ti = table_instance_rehash(ti, ti->n_buckets);
>> > + new_ti = flow_table_rehash(ti, ti->n_buckets, false);
>> > + if (ufid_ti && table->ufid_count > ufid_ti->n_buckets)
>> > + new_ufid_ti = flow_table_expand(ufid_ti, true);
>> >
>> > if (new_ti) {
>> >
>> > rcu_assign_pointer(table->ti, new_ti);
>> >
>> > - table_instance_destroy(ti, true);
>> > + call_rcu(&ti->rcu, flow_tbl_destroy_rcu_cb);
>> >
>> > table->last_rehash = jiffies;
>> >
>> > }
>> >
>> > + if (new_ufid_ti) {
>> > + rcu_assign_pointer(table->ufid_ti, new_ufid_ti);
>> > + call_rcu(&ufid_ti->rcu, flow_tbl_destroy_rcu_cb);
>> > + }
>> > + return 0;
>> > +}
>>
>> Insert function can be simplified by first updating flow-table and
>> then updating ufid table.
>
> Sure.
>
>
>> > #define OVS_FLOW_ATTR_MAX (__OVS_FLOW_ATTR_MAX - 1)
>> >
>> > /**
>> >
>> > + * enum ovs_ufid_attr - Unique identifier types.
>> > + *
>> > + * @OVS_UFID_ATTR_FLAGS: A 32-bit value specifying changes to the
>> > behaviour of + * the current %OVS_FLOW_CMD_* request. Optional for all
>> > requests. + * @OVS_UFID_ATTR_ID: A unique identifier for a flow.
>> > + */
>> > +enum ovs_ufid_attr {
>> > + OVS_UFID_ATTR_UNSPEC,
>> > + OVS_UFID_ATTR_FLAGS, /* u32 of OVS_UFID_F_* */
>> > + OVS_UFID_ATTR_ID, /* variable length identifier. */
>> > + __OVS_UFID_ATTR_MAX
>> > +};
>> > +
>> > +#define OVS_UFID_ATTR_MAX (__OVS_UFID_ATTR_MAX - 1)
>> > +
>> > +/**
>> > + * Omit attributes for notifications.
>> > + *
>> > + * If a datapath request contains an OVS_UFID_F_OMIT_* flag, then the
>> > datapath + * may omit the corresponding 'ovs_flow_attr' from the
>> > response. + */
>> > +#define OVS_UFID_F_OMIT_KEY (1 << 0)
>> > +#define OVS_UFID_F_OMIT_MASK (1 << 1)
>> > +#define OVS_UFID_F_OMIT_ACTIONS (1 << 2)
>> > +
>>
>> These flags are related to flow operations. So OVS_UFID_ATTR_FLAGS
>> should be part of enum ovs_flow_attr.
>> This way we do not need to make UFID nested attr.
>
> OK, I'll shift it out.
>
> Thanks for the review, I'll work on a fresh revision.
^ 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