|
Re: agenda: IO Visor TSC/Dev Meeting
Hello Brenden!
I’m not sure if it counts as an agenda item, but I’m interested in
recording process events using tracepoints, and I would like to know
what are the best practices when attempting
Hello Brenden!
I’m not sure if it counts as an agenda item, but I’m interested in
recording process events using tracepoints, and I would like to know
what are the best practices when attempting
|
By
alessandro.gario@...
·
#1769
·
|
|
Re: sockmap redirect doesn't work all the time
Hi Ferenc,
I think sock_ops is a good option for me, it seems the cilium project also use this to accelerate networks.
Yes, all TCP connection established. There're no connection pressures and I send
Hi Ferenc,
I think sock_ops is a good option for me, it seems the cilium project also use this to accelerate networks.
Yes, all TCP connection established. There're no connection pressures and I send
|
By
Forrest Chen
·
#1768
·
|
|
agenda: IO Visor TSC/Dev Meeting
Hi All,
We have the bi-weekly phone conference scheduled for two days from now, does
anybody have a discussion topic to add to the agenda? As a reminder, we are
planning to hold the meeting only if
Hi All,
We have the bi-weekly phone conference scheduled for two days from now, does
anybody have a discussion topic to add to the agenda? As a reminder, we are
planning to hold the meeting only if
|
By
Brenden Blanco
·
#1767
·
|
|
Re: [PATCHv5 RFC 1/3] BPF: New helper to obtainnamespace data from current task.
<cneirabustos@...> wrote:
looks good. A couple of comments below.
reverse Christmas order.
Looks like -EINVAL is returned for all error cases.
This is suboptimal. There are cases where other
<cneirabustos@...> wrote:
looks good. A couple of comments below.
reverse Christmas order.
Looks like -EINVAL is returned for all error cases.
This is suboptimal. There are cases where other
|
By
Yonghong Song
·
#1766
·
|
|
Re: [PATCHv5 RFC 1/3] BPF: New helper to obtainnamespace data from current task.
Hi Yonghong,
I had time yesterday to finish the code to avoid using getname_kernel , self-tests run ok with expected results.
Here is the current code to avoid the getname_kernel call.
diff
Hi Yonghong,
I had time yesterday to finish the code to avoid using getname_kernel , self-tests run ok with expected results.
Here is the current code to avoid the getname_kernel call.
diff
|
By
neirac
·
#1765
·
|
|
Re: [PATCHv5 RFC 1/3] BPF: New helper to obtain namespace data from current task.
Carlos,
Any update on this? It would be good to submit the patch earlier for a
release cycle
so we got a chance it may be accepted in the current release cycle.
<cneirabustos@...> wrote:
Carlos,
Any update on this? It would be good to submit the patch earlier for a
release cycle
so we got a chance it may be accepted in the current release cycle.
<cneirabustos@...> wrote:
|
By
Yonghong Song
·
#1764
·
|
|
Re: sockmap redirect doesn't work all the time
Hi!
Well it seems like a different problem from what I first thought. I have a few idea, maybe some of them helps:
1. If you able to modify the source code of user space receiver program, maybe try to
Hi!
Well it seems like a different problem from what I first thought. I have a few idea, maybe some of them helps:
1. If you able to modify the source code of user space receiver program, maybe try to
|
By
Ferenc Fejes
·
#1763
·
|
|
Re: AF_XDP query
Hi Kanthi,
In the case of OVS AF_XDP netdev, we've used multiple PMD threads.
Each thread has its own AF_XDP socket and its own UMEM bind to each rx queue.
I think multiple processes should also
Hi Kanthi,
In the case of OVS AF_XDP netdev, we've used multiple PMD threads.
Each thread has its own AF_XDP socket and its own UMEM bind to each rx queue.
I think multiple processes should also
|
By
William Tu
·
#1762
·
|
|
Re: AF_XDP query
Hi Kanthi,
Yes, it's possible!
Björn
Hi Kanthi,
Yes, it's possible!
Björn
|
By
Bjorn Topel
·
#1761
·
|
|
Re: the size of BPF_MAP_TYPE_PERCPU_ARRAY doesn't match the number of CPU
On Thu, Aug 1, 2019 at 07:16 PM, Yonghong Song wrote:
I guess you mean value size. here.
When you got the values from kernel, the value size is rounded to 8.
On Thu, Aug 1, 2019 at 07:16 PM, Yonghong Song wrote:
I guess you mean value size. here.
When you got the values from kernel, the value size is rounded to 8.
|
By
Forrest Chen
·
#1760
·
|
|
Re: the size of BPF_MAP_TYPE_PERCPU_ARRAY doesn't match the number of CPU
For array map, the key type must be 32bit int.
```
int array_map_alloc_check(union bpf_attr *attr)
{
bool percpu = attr->map_type == BPF_MAP_TYPE_PERCPU_ARRAY;
int numa_node =
For array map, the key type must be 32bit int.
```
int array_map_alloc_check(union bpf_attr *attr)
{
bool percpu = attr->map_type == BPF_MAP_TYPE_PERCPU_ARRAY;
int numa_node =
|
By
Yonghong Song
·
#1759
·
|
|
Re: the size of BPF_MAP_TYPE_PERCPU_ARRAY doesn't match the number of CPU
map defined:
struct bpf_map_def SEC("maps/protocount") proto_count = {
.type = BPF_MAP_TYPE_PERCPU_ARRAY,
.key_size = sizeof(__u32),
.value_size = sizeof(__u32),
.max_entries =
map defined:
struct bpf_map_def SEC("maps/protocount") proto_count = {
.type = BPF_MAP_TYPE_PERCPU_ARRAY,
.key_size = sizeof(__u32),
.value_size = sizeof(__u32),
.max_entries =
|
By
Forrest Chen
·
#1758
·
|
|
Re: the size of BPF_MAP_TYPE_PERCPU_ARRAY doesn't match the number of CPU
Could you post how to reproduce the issue so people can help?
If you do provide reproducible steps, could you submit an issue to
help tracking?
Thanks,
Could you post how to reproduce the issue so people can help?
If you do provide reproducible steps, could you submit an issue to
help tracking?
Thanks,
|
By
Yonghong Song
·
#1757
·
|
|
the size of BPF_MAP_TYPE_PERCPU_ARRAY doesn't match the number of CPU
Hi all,
I define a BPF_MAP_TYPE_PERCPU_ARRAY and use it to count packets in the xdp program. When I read the map from userspace program, I find that the entry number doesn't match local CPU numbers. I
Hi all,
I define a BPF_MAP_TYPE_PERCPU_ARRAY and use it to count packets in the xdp program. When I read the map from userspace program, I find that the entry number doesn't match local CPU numbers. I
|
By
Forrest Chen
·
#1756
·
|
|
AF_XDP query
Hi,
Is it possible to have 2 processes each with its own AF_XDP socket and its own UMEM?
Thanks,
Kanthi
Hi,
Is it possible to have 2 processes each with its own AF_XDP socket and its own UMEM?
Thanks,
Kanthi
|
By
Kanthi P <Pavuluri.kanthi@...>
·
#1755
·
|
|
Re: sockmap redirect doesn't work all the time
Hi Ferenc:
The packets are really small, I just send a curl get request. Sometimes I can receive the packets from my program, I think it is because the packets arrive before I set the socket desc so
Hi Ferenc:
The packets are really small, I just send a curl get request. Sometimes I can receive the packets from my program, I think it is because the packets arrive before I set the socket desc so
|
By
Forrest Chen
·
#1754
·
|
|
Re: [PATCHv5 RFC 1/3] BPF: New helper to obtain namespace data from current task.
Thanks Yonghong!.
Yes, I was looking at filename_lookup today on how to do it, I'll work on that.
Thank you very much.
Thanks Yonghong!.
Yes, I was looking at filename_lookup today on how to do it, I'll work on that.
Thank you very much.
|
By
neirac
·
#1753
·
|
|
Re: [PATCHv5 RFC 1/3] BPF: New helper to obtain namespace data from current task.
<alexei.starovoitov@...> wrote:
Looks like we can call filename_lookup() directly. We do not need to
call getname_kernel().
We know the exact path name. We can do a atomic allocation inside the
<alexei.starovoitov@...> wrote:
Looks like we can call filename_lookup() directly. We do not need to
call getname_kernel().
We know the exact path name. We can do a atomic allocation inside the
|
By
Yonghong Song
·
#1752
·
|
|
Re: [PATCHv5 RFC 1/3] BPF: New helper to obtain namespace data from current task.
please figure out how to get pidns_info w/o calling into getname_kernel().
please figure out how to get pidns_info w/o calling into getname_kernel().
|
By
Alexei Starovoitov
·
#1751
·
|
|
Re: [PATCHv5 RFC 1/3] BPF: New helper to obtain namespace data from current task.
Hey Yonghong,
I have changed getname_kernel interface to specify the allocation type,
all previous callers preserve GFP_KERNEL as the allocation type, after this change
getname_kernel could be used
Hey Yonghong,
I have changed getname_kernel interface to specify the allocation type,
all previous callers preserve GFP_KERNEL as the allocation type, after this change
getname_kernel could be used
|
By
neirac
·
#1750
·
|