Re: [v1,net-next 3/4] net: qos: police action add index for tc flower offloading

On 2020-06-24 8:34 p.m., Po Liu wrote: -Original Message- That is the point i was trying to get to. Basically: You have a counter table which is referenced by "index" You also have a meter/policer table which is referenced by "index". They should be one same group and same

Re: [v1,net-next 3/4] net: qos: police action add index for tc flower offloading

On 2020-06-23 7:52 p.m., Po Liu wrote: Hi Jamal, My question: Is this any different from how stats are structured? [..] My question: Why cant you apply the same semantics for the counters? Does your hardware have an indexed counter/stats table? If yes then you Yes, That is the

Re: [v1,net-next 3/4] net: qos: police action add index for tc flower offloading

On 2020-06-23 7:55 a.m., Po Liu wrote: [..] My question: Is this any different from how stats are structured? I don't know I fully catch the question. Are you trying to get how many frames for each filter chain passing one index policing action? If one index police action bind to multiple

Re: [v1,net-next 3/4] net: qos: police action add index for tc flower offloading

This certainly brings an interesting point which i brought up earlier when Jiri was doing offloading of stats. In this case the action index is being used as the offloaded policer index (note: there'd need to be a check whether the index is infact acceptable to the h/w etc unless there 2^32

Re: [PATCH net-next 0/2] Change tc action identifiers to be more consistent

On 2019-02-07 2:45 a.m., Eli Cohen wrote: This two patch series modifies TC actions identifiers to be more consistent and also puts them in one place so new identifiers numbers can be chosen more easily. For the series: Acked-by: Jamal Hadi Salim cheers, jamal

Re: [PATCH/RFC] Make perf_event_open() propagate errors for use in bpf_perf_event_open()

est built. Works as advertised ;-> Tested-by: Jamal Hadi Salim cheers, jamal

Re: linux-next: manual merge of the net-next tree with the net tree

On 2018-10-08 9:21 p.m., Stephen Rothwell wrote: Hi all, Today's linux-next merge of the net-next tree got a conflict in: net/sched/cls_u32.c between commit: 6d4c407744dd ("net: sched: cls_u32: fix hnode refcounting") from the net tree and commit: a030598690c6 ("net: sched:

Re: linux-next: manual merge of the net-next tree with the net tree

On 2018-10-08 9:21 p.m., Stephen Rothwell wrote: Hi all, Today's linux-next merge of the net-next tree got a conflict in: net/sched/cls_u32.c between commit: 6d4c407744dd ("net: sched: cls_u32: fix hnode refcounting") from the net tree and commit: a030598690c6 ("net: sched:

Re: [PATCH net-next v2] net: sched: don't disable bh when accessing action idr

all action idr spinlock usage with regular calls that do not disable bh. Signed-off-by: Vlad Buslov <vla...@mellanox.com> Acked-by: Jamal Hadi Salim <j...@mojatatu.com> cheers, jamal

Re: [PATCH net-next v2] net: sched: don't disable bh when accessing action idr

all action idr spinlock usage with regular calls that do not disable bh. Signed-off-by: Vlad Buslov Acked-by: Jamal Hadi Salim cheers, jamal

Re: [PATCH 00/14] Modify action API for implementing lockless actions

On 14/05/18 04:46 PM, Vlad Buslov wrote: On Mon 14 May 2018 at 18:03, Jamal Hadi Salim <j...@mojatatu.com> wrote: On 14/05/18 10:27 AM, Vlad Buslov wrote: Hello Jamal, I'm trying to run tdc, but keep getting following error even on clean branch without my patches: Vlad, not sure

Re: [PATCH 00/14] Modify action API for implementing lockless actions

On 14/05/18 04:46 PM, Vlad Buslov wrote: On Mon 14 May 2018 at 18:03, Jamal Hadi Salim wrote: On 14/05/18 10:27 AM, Vlad Buslov wrote: Hello Jamal, I'm trying to run tdc, but keep getting following error even on clean branch without my patches: Vlad, not sure if you saw my email: Apply

Re: [PATCH 00/14] Modify action API for implementing lockless actions

On 14/05/18 10:27 AM, Vlad Buslov wrote: Currently, all netlink protocol handlers for updating rules, actions and qdiscs are protected with single global rtnl lock which removes any possibility for parallelism. This patch set is a first step to remove rtnl lock dependency from TC rules update

Re: [PATCH 00/14] Modify action API for implementing lockless actions

On 14/05/18 10:27 AM, Vlad Buslov wrote: Currently, all netlink protocol handlers for updating rules, actions and qdiscs are protected with single global rtnl lock which removes any possibility for parallelism. This patch set is a first step to remove rtnl lock dependency from TC rules update

Re: [PATCH net-next 2/2] net sched act_vlan: VLAN action rewrite to use RCU lock/unlock and update

Acked-by: Jamal Hadi Salim <j...@mojatatu.com> cheers, jamal

Re: [PATCH net-next 2/2] net sched act_vlan: VLAN action rewrite to use RCU lock/unlock and update

On 17-10-10 10:33 PM, Manish Kurup wrote: Using a spinlock in the VLAN action causes performance issues when the VLAN action is used on multiple cores. Rewrote the VLAN action to use RCU read locking for reads and updates instead. Signed-off-by: Manish Kurup Acked-by: Jamal Hadi Salim

Re: [PATCH] net/sched: act_skbmod: remove unneeded rcu_read_unlock in tcf_skbmod_dump

On 17-03-04 07:01 PM, Alexey Khoroshilov wrote: Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov <khoroshi...@ispras.ru> Acked-by: Jamal Hadi Salim <j...@mojatatu.com> cheers, jamal

Re: [PATCH] net/sched: act_skbmod: remove unneeded rcu_read_unlock in tcf_skbmod_dump

On 17-03-04 07:01 PM, Alexey Khoroshilov wrote: Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov Acked-by: Jamal Hadi Salim cheers, jamal

Re: [PATCH]net:sched:release lock before tcf_dump_walker() normal return to avoid deadlock

On 16-12-06 12:36 AM, Feng Deng wrote: From: Feng Deng release lock before tcf_dump_walker() normal return to avoid deadlock /Scratching my head. I am probably missing something obvious. What are the condition under which this deadlock will happen? Do you have a testcase

Re: [PATCH]net:sched:release lock before tcf_dump_walker() normal return to avoid deadlock

On 16-12-06 12:36 AM, Feng Deng wrote: From: Feng Deng release lock before tcf_dump_walker() normal return to avoid deadlock /Scratching my head. I am probably missing something obvious. What are the condition under which this deadlock will happen? Do you have a testcase we can try?

Re: [PATCH v5] net: ip, diag -- Add diag interface for raw sockets

On 16-09-28 08:45 AM, Cyrill Gorcunov wrote: Note: inet_diag somewhere has a netlink structure that has a hole. I pointed it out to Eric D. and he said we cant add it now because it would break ABI. Naming holes generated by a compiler for alignment sake should not break abi (because

Re: [PATCH v5] net: ip, diag -- Add diag interface for raw sockets

On 16-09-28 08:45 AM, Cyrill Gorcunov wrote: Note: inet_diag somewhere has a netlink structure that has a hole. I pointed it out to Eric D. and he said we cant add it now because it would break ABI. Naming holes generated by a compiler for alignment sake should not break abi (because

Re: [PATCH v5] net: ip, diag -- Add diag interface for raw sockets

On 16-09-28 08:27 AM, Jamal Hadi Salim wrote: On 16-09-28 08:16 AM, David Miller wrote: From: Jamal Hadi Salim <j...@mojatatu.com> Date: Wed, 28 Sep 2016 08:09:28 -0400 On 16-09-28 08:07 AM, David Miller wrote: Right, it would be legal for an existing user to have code that expl

Re: [PATCH v5] net: ip, diag -- Add diag interface for raw sockets

On 16-09-28 08:27 AM, Jamal Hadi Salim wrote: On 16-09-28 08:16 AM, David Miller wrote: From: Jamal Hadi Salim Date: Wed, 28 Sep 2016 08:09:28 -0400 On 16-09-28 08:07 AM, David Miller wrote: Right, it would be legal for an existing user to have code that explicitly initializes every member

Re: [PATCH v5] net: ip, diag -- Add diag interface for raw sockets

On 16-09-28 08:16 AM, David Miller wrote: From: Jamal Hadi Salim <j...@mojatatu.com> Date: Wed, 28 Sep 2016 08:09:28 -0400 On 16-09-28 08:07 AM, David Miller wrote: Right, it would be legal for an existing user to have code that explicitly initializes every member of the structure, inc

Re: [PATCH v5] net: ip, diag -- Add diag interface for raw sockets

On 16-09-28 08:16 AM, David Miller wrote: From: Jamal Hadi Salim Date: Wed, 28 Sep 2016 08:09:28 -0400 On 16-09-28 08:07 AM, David Miller wrote: Right, it would be legal for an existing user to have code that explicitly initializes every member of the structure, including 'pad'. So we have

Re: [PATCH v5] net: ip, diag -- Add diag interface for raw sockets

On 16-09-28 08:07 AM, David Miller wrote: Right, it would be legal for an existing user to have code that explicitly initializes every member of the structure, including 'pad'. So we have to keep that member around, at a minimum, for their sake. I think we need to start labelling any new pad

Re: [PATCH v5] net: ip, diag -- Add diag interface for raw sockets

On 16-09-28 08:07 AM, David Miller wrote: Right, it would be legal for an existing user to have code that explicitly initializes every member of the structure, including 'pad'. So we have to keep that member around, at a minimum, for their sake. I think we need to start labelling any new pad

Re: [PATCH v5] net: ip, diag -- Add diag interface for raw sockets

On 16-09-28 07:27 AM, Cyrill Gorcunov wrote: On Wed, Sep 28, 2016 at 07:06:26AM -0400, Jamal Hadi Salim wrote: This structure is uapi, so anyone has complete rights to reference @pad in the userspace programs. Sure it would be more clear to remove the @pad completely, but if we choose so I

Re: [PATCH v5] net: ip, diag -- Add diag interface for raw sockets

On 16-09-28 07:27 AM, Cyrill Gorcunov wrote: On Wed, Sep 28, 2016 at 07:06:26AM -0400, Jamal Hadi Salim wrote: This structure is uapi, so anyone has complete rights to reference @pad in the userspace programs. Sure it would be more clear to remove the @pad completely, but if we choose so I

Re: [PATCH v5] net: ip, diag -- Add diag interface for raw sockets

On 16-09-28 06:51 AM, Cyrill Gorcunov wrote: On Wed, Sep 28, 2016 at 06:43:01AM -0400, Jamal Hadi Salim wrote: [..] I dont know how compilation will fail but you may be right with note: that is not how pads have been used in the past. They are supposed to cosmetic annotation which indicates

Re: [PATCH v5] net: ip, diag -- Add diag interface for raw sockets

On 16-09-28 06:51 AM, Cyrill Gorcunov wrote: On Wed, Sep 28, 2016 at 06:43:01AM -0400, Jamal Hadi Salim wrote: [..] I dont know how compilation will fail but you may be right with note: that is not how pads have been used in the past. They are supposed to cosmetic annotation which indicates

Re: [PATCH v5] net: ip, diag -- Add diag interface for raw sockets

On 16-09-28 06:17 AM, Cyrill Gorcunov wrote: On Wed, Sep 28, 2016 at 06:08:00AM -0400, Jamal Hadi Salim wrote: ... @@ -38,7 +38,10 @@ struct inet_diag_req_v2 { __u8sdiag_family; __u8sdiag_protocol; __u8idiag_ext; - __u8pad; + union

Re: [PATCH v5] net: ip, diag -- Add diag interface for raw sockets

On 16-09-28 06:17 AM, Cyrill Gorcunov wrote: On Wed, Sep 28, 2016 at 06:08:00AM -0400, Jamal Hadi Salim wrote: ... @@ -38,7 +38,10 @@ struct inet_diag_req_v2 { __u8sdiag_family; __u8sdiag_protocol; __u8idiag_ext; - __u8pad; + union

Re: [PATCH v5] net: ip, diag -- Add diag interface for raw sockets

On 16-09-28 05:03 AM, Cyrill Gorcunov wrote: In criu we are actively using diag interface to collect sockets present in the system when dumping applications. And while for unix, tcp, udp[lite], packet, netlink it works as expected, the raw sockets do not have. Thus add it. v2: - add missing

Re: [PATCH v5] net: ip, diag -- Add diag interface for raw sockets

On 16-09-28 05:03 AM, Cyrill Gorcunov wrote: In criu we are actively using diag interface to collect sockets present in the system when dumping applications. And while for unix, tcp, udp[lite], packet, netlink it works as expected, the raw sockets do not have. Thus add it. v2: - add missing

Re: [BUG] act_ife: sleeping functions called in atomic context

On 16-06-17 01:31 PM, Cong Wang wrote: My patch is against -net. (I see you already figured out your patch is missing in -net-next.) Ok, should have re-read this email before working on the patch;-> Or are you suggesting to rebase it for -net-next? I think it fixes some real bug so -net is

Re: [BUG] act_ife: sleeping functions called in atomic context

On 16-06-17 01:31 PM, Cong Wang wrote: My patch is against -net. (I see you already figured out your patch is missing in -net-next.) Ok, should have re-read this email before working on the patch;-> Or are you suggesting to rebase it for -net-next? I think it fixes some real bug so -net is

Re: [BUG] act_ife: sleeping functions called in atomic context

On 16-06-17 01:38 AM, Cong Wang wrote: On Thu, Jun 16, 2016 at 7:14 PM, Cong Wang wrote: I think we can just remove that tcf_lock, I am testing a patch now. Please try the attached patch, I will do more tests tomorrow. Thanks! Cong, What tree are you using? I

Re: [BUG] act_ife: sleeping functions called in atomic context

On 16-06-17 01:38 AM, Cong Wang wrote: On Thu, Jun 16, 2016 at 7:14 PM, Cong Wang wrote: I think we can just remove that tcf_lock, I am testing a patch now. Please try the attached patch, I will do more tests tomorrow. Thanks! Cong, What tree are you using? I dont see the time

Re: [BUG] act_ife: sleeping functions called in atomic context

On 16-06-16 05:43 PM, Cong Wang wrote: On Thu, Jun 16, 2016 at 1:50 PM, Alexey Khoroshilov wrote: tcf_ife_init() contains a big chunk of code executed with ife->tcf_lock spinlock held. But that code contains several calls to sleeping functions: populate_metalist() and

Re: [BUG] act_ife: sleeping functions called in atomic context

On 16-06-16 05:43 PM, Cong Wang wrote: On Thu, Jun 16, 2016 at 1:50 PM, Alexey Khoroshilov wrote: tcf_ife_init() contains a big chunk of code executed with ife->tcf_lock spinlock held. But that code contains several calls to sleeping functions: populate_metalist() and use_all_metadata()

Re: [PATCH net-next V2] tun: introduce tx skb ring

On 16-06-15 07:52 AM, Jamal Hadi Salim wrote: > On 16-06-15 04:38 AM, Jason Wang wrote: >> We used to queue tx packets in sk_receive_queue, this is less >> efficient since it requires spinlocks to synchronize between producer > > So this is more exercising the skb array

Re: [PATCH net-next V2] tun: introduce tx skb ring

On 16-06-15 07:52 AM, Jamal Hadi Salim wrote: > On 16-06-15 04:38 AM, Jason Wang wrote: >> We used to queue tx packets in sk_receive_queue, this is less >> efficient since it requires spinlocks to synchronize between producer > > So this is more exercising the skb array

Re: [PATCH net-next V2] tun: introduce tx skb ring

On 16-06-15 04:38 AM, Jason Wang wrote: > We used to queue tx packets in sk_receive_queue, this is less > efficient since it requires spinlocks to synchronize between producer > and consumer. > > This patch tries to address this by: > > - introduce a new mode which will be only enabled with

Re: [PATCH net-next V2] tun: introduce tx skb ring

On 16-06-15 04:38 AM, Jason Wang wrote: > We used to queue tx packets in sk_receive_queue, this is less > efficient since it requires spinlocks to synchronize between producer > and consumer. > > This patch tries to address this by: > > - introduce a new mode which will be only enabled with

Re: Deleting child qdisc doesn't reset parent to default qdisc?

On 16-04-14 01:49 PM, Eric Dumazet wrote: And what would be the chosen behavior ? TBF is probably a bad example because it started life as a classless qdisc. There was only one built-in fifo queue that was shaped. Then someone made it classful and changed this behavior. To me it sounds

Re: Deleting child qdisc doesn't reset parent to default qdisc?

On 16-04-14 01:49 PM, Eric Dumazet wrote: And what would be the chosen behavior ? TBF is probably a bad example because it started life as a classless qdisc. There was only one built-in fifo queue that was shaped. Then someone made it classful and changed this behavior. To me it sounds

Re: [PATCH net v3 2/4] net: add rx_nohandler stat counter

On 16-02-09 03:40 AM, David Miller wrote: From: Eric Dumazet Date: Mon, 08 Feb 2016 14:57:40 -0800 Whole point of TLV is that it allows us to add new fields at the end of the structures. ... Look at iproute2, you were the one adding in 2004 code to cope with various tcp_info sizes. So 12

Re: [PATCH net v3 2/4] net: add rx_nohandler stat counter

On 16-02-09 03:40 AM, David Miller wrote: From: Eric Dumazet Date: Mon, 08 Feb 2016 14:57:40 -0800 Whole point of TLV is that it allows us to add new fields at the end of the structures. ... Look at iproute2, you were the one adding in 2004 code to cope with

Re: [PATCH 0/7] Freescale DPAA FMan FLIB(s)

Hi Emil, On 03/05/15 10:04, Emil Medve wrote: Hello Jamal, On 03/05/2015 08:35 AM, Jamal Hadi Salim wrote: Hi Emil, No. All the kernel drivers/code we want to upstream is meant to stand on its own and be used the "normal" Linux/Unix way Ok, thanks - that was my only con

Re: [PATCH 0/7] Freescale DPAA FMan FLIB(s)

Hi Emil, On 03/05/15 10:04, Emil Medve wrote: Hello Jamal, On 03/05/2015 08:35 AM, Jamal Hadi Salim wrote: Hi Emil, No. All the kernel drivers/code we want to upstream is meant to stand on its own and be used the normal Linux/Unix way Ok, thanks - that was my only concern. Note

Re: [PATCH 0/7] Freescale DPAA FMan FLIB(s)

Hi Emil, On 03/05/15 08:48, Emil Medve wrote: The intent is to upstream the entire suite of the DPAA drivers. All the drivers are still WIP, but B/QMan have been already presented to the upstream community and this is the first attempt to publish (some low level code of) the FMan driver. As we

Re: [PATCH 0/7] Freescale DPAA FMan FLIB(s)

On 03/05/15 00:45, Emil Medve wrote: From: Igal Liberman The Freescale Data Path Acceleration Architecture (DPAA) is a set of hardware components on specific QorIQ P and T series multicore processors. This architecture provides the infrastructure to support simplified sharing of networking

Re: [PATCH 0/7] Freescale DPAA FMan FLIB(s)

On 03/05/15 00:45, Emil Medve wrote: From: Igal Liberman igal.liber...@freescale.com The Freescale Data Path Acceleration Architecture (DPAA) is a set of hardware components on specific QorIQ P and T series multicore processors. This architecture provides the infrastructure to support

Re: [PATCH 0/7] Freescale DPAA FMan FLIB(s)

Hi Emil, On 03/05/15 08:48, Emil Medve wrote: The intent is to upstream the entire suite of the DPAA drivers. All the drivers are still WIP, but B/QMan have been already presented to the upstream community and this is the first attempt to publish (some low level code of) the FMan driver. As we

Re: [PATCH v2 0/3] net: Add Keystone NetCP ethernet driver support

On 09/09/14 11:19, Santosh Shilimkar wrote: All the documentation is open including packet accelerator offload in ti.com. Very nice. Would you do me a kindness and point to the switch interface documentation (and other ones on that soc)? We got such requests from customers but couldn't

Re: [PATCH v2 0/3] net: Add Keystone NetCP ethernet driver support

On 09/09/14 11:19, Santosh Shilimkar wrote: All the documentation is open including packet accelerator offload in ti.com. Very nice. Would you do me a kindness and point to the switch interface documentation (and other ones on that soc)? We got such requests from customers but couldn't

Re: [PATCH v2 0/3] net: Add Keystone NetCP ethernet driver support

On 09/08/14 10:41, Santosh Shilimkar wrote: The NetCP plugin module infrastructure use all the standard kernel infrastructure and its very tiny. So i found this manual here: http://www.silica.com/fileadmin/02_Products/Productdetails/Texas_Instruments/SILICA_TI_66AK2E05-ds.pdf Glad there is

Re: [PATCH v2 0/3] net: Add Keystone NetCP ethernet driver support

On 09/08/14 10:41, Santosh Shilimkar wrote: The NetCP plugin module infrastructure use all the standard kernel infrastructure and its very tiny. So i found this manual here: http://www.silica.com/fileadmin/02_Products/Productdetails/Texas_Instruments/SILICA_TI_66AK2E05-ds.pdf Glad there is

Re: [PATCH v2 2/3] net: Add Keystone NetCP ethernet driver

On 08/15/14 11:12, Santosh Shilimkar wrote: I am curious about these two calls below(netcp_process_one_rx_packet and netcp_tx_submit_skb): On tx you seem to be broadcasting to all "sub-modules" and on receive you seem to be invoking from all as well. I couldnt find the code for any of the

Re: [PATCH v2 2/3] net: Add Keystone NetCP ethernet driver

On 08/15/14 11:12, Santosh Shilimkar wrote: I am curious about these two calls below(netcp_process_one_rx_packet and netcp_tx_submit_skb): On tx you seem to be broadcasting to all sub-modules and on receive you seem to be invoking from all as well. I couldnt find the code for any of the

Re: [RFC PATCH] xfrm: fix handling of XFRM policies mark and mask.

On 13-02-06 09:39 AM, Emmanuel Thierry wrote: I think you misread the example ! I did ;-> Marks are both 1, masks are different. This case is more complex than a policy with no mark (so mark=0 and mask=0) versus a policy with an exact mark (so mark=1 and mask=0x), and i wanted

Re: [RFC PATCH] xfrm: fix handling of XFRM policies mark and mask.

On 13-02-06 08:53 AM, Emmanuel Thierry wrote: Actually, we didn't think about this problem since we work with priorities, putting the default policy (without a mark) at a minor priority than the marked one. I think priorities are the way to go in cases of ambiguity. Your remark makes

Re: [RFC PATCH] xfrm: fix handling of XFRM policies mark and mask.

On 13-02-06 08:53 AM, Emmanuel Thierry wrote: Actually, we didn't think about this problem since we work with priorities, putting the default policy (without a mark) at a minor priority than the marked one. I think priorities are the way to go in cases of ambiguity. Your remark makes

Re: [RFC PATCH] xfrm: fix handling of XFRM policies mark and mask.

On 13-02-06 09:39 AM, Emmanuel Thierry wrote: I think you misread the example ! I did ;- Marks are both 1, masks are different. This case is more complex than a policy with no mark (so mark=0 and mask=0) versus a policy with an exact mark (so mark=1 and mask=0x), and i wanted to

Re: [net V2] act_mirred: do not drop packets when fails to mirror it

> > To solve the issue, the patch does not drop packets when kernel fails to > mirror > it, and only drop the redirected packets. > > Signed-off-by: Jason Wang Signed-off-by: Jamal Hadi Salim cheers, jamal -- To unsubscribe from this list: send the line "unsubscribe l

Re: [net V2] act_mirred: do not drop packets when fails to mirror it

not drop packets when kernel fails to mirror it, and only drop the redirected packets. Signed-off-by: Jason Wang jasow...@redhat.com Signed-off-by: Jamal Hadi Salim j...@mojatatu.com cheers, jamal -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body

Re: [PATCH] act_mirred: do not drop packets when fails to mirror it

On Wed, 2012-08-15 at 21:42 +0800, Jason Wang wrote: > > I met it actually through the following steps: > > - start a kvm guest with tap and make it to be an interface of the bridge > - mirror the ingress traffic of the bridge to the tap > - terminate the qemu process, the tap device is then

Re: [PATCH] act_mirred: do not drop packets when fails to mirror it

On Wed, 2012-08-15 at 17:37 +0800, Jason Wang wrote: > We drop packet unconditionally when we fail to mirror it. This is not intended > in some cases. Hi Jason, Did you actually notice the behavior you described or were you going by the XXX comment I had in the code? cheers, jamal -- To

Re: [PATCH 15/21] net sched: Pass the skb into change so it can access NETLINK_CB

rtnetlink skb into > the the classifier change routines as that is generally the more useful > parameter. > > Cc: Jamal Hadi Salim > Acked-by: Serge Hallyn > Signed-off-by: Eric W. Biederman Acked-by: Jamal Hadi Salim cheers, jamal -- To unsubscribe from this list: send th

Re: [PATCH 15/21] net sched: Pass the skb into change so it can access NETLINK_CB

into the the classifier change routines as that is generally the more useful parameter. Cc: Jamal Hadi Salim j...@mojatatu.com Acked-by: Serge Hallyn serge.hal...@canonical.com Signed-off-by: Eric W. Biederman ebied...@xmission.com Acked-by: Jamal Hadi Salim j...@mojatatu.com cheers, jamal

Re: [PATCH] act_mirred: do not drop packets when fails to mirror it

On Wed, 2012-08-15 at 17:37 +0800, Jason Wang wrote: We drop packet unconditionally when we fail to mirror it. This is not intended in some cases. Hi Jason, Did you actually notice the behavior you described or were you going by the XXX comment I had in the code? cheers, jamal -- To

Re: [PATCH] act_mirred: do not drop packets when fails to mirror it

On Wed, 2012-08-15 at 21:42 +0800, Jason Wang wrote: I met it actually through the following steps: - start a kvm guest with tap and make it to be an interface of the bridge - mirror the ingress traffic of the bridge to the tap - terminate the qemu process, the tap device is then removed