On 2017/3/31 11:24, Alexei Starovoitov wrote:
On 3/30/17 8:12 PM, Wangnan (F) wrote:
On 2017/3/31 10:57, Alexei Starovoitov wrote:
On 3/30/17 7:53 PM, Wangnan (F) wrote:
I suggest using a CONFIG option to enable/disable code in
test_run.o to reduce attack plane.
attack plane? what attack
On 3/30/17 8:12 PM, Wangnan (F) wrote:
On 2017/3/31 10:57, Alexei Starovoitov wrote:
On 3/30/17 7:53 PM, Wangnan (F) wrote:
I suggest using a CONFIG option to enable/disable code in
test_run.o to reduce attack plane.
attack plane? what attack do you see and how config helps?
I think all
On 2017/3/31 10:57, Alexei Starovoitov wrote:
On 3/30/17 7:53 PM, Wangnan (F) wrote:
I suggest using a CONFIG option to enable/disable code in
test_run.o to reduce attack plane.
attack plane? what attack do you see and how config helps?
I think all testing features are not required to be
On 3/30/17 7:53 PM, Wangnan (F) wrote:
I suggest using a CONFIG option to enable/disable code in
test_run.o to reduce attack plane.
attack plane? what attack do you see and how config helps?
On 2017/3/31 9:31, Alexei Starovoitov wrote:
development and testing of networking bpf programs is quite cumbersome.
Despite availability of user space bpf interpreters the kernel is
the ultimate authority and execution environment.
Current test frameworks for TC include creation of netns, veth
development and testing of networking bpf programs is quite cumbersome.
Despite availability of user space bpf interpreters the kernel is
the ultimate authority and execution environment.
Current test frameworks for TC include creation of netns, veth,
qdiscs and use of various packet generators jus
