&vp->tx_poll, vector_tx_poll, (unsigned long)vp);
+ tasklet_setup(&vp->tx_poll, vector_tx_poll);
INIT_WORK(&vp->reset_tx, vector_reset_tx);
timer_setup(&vp->tl, vector_timer_expire, 0);
Acked-By: Anton Ivanov
--
Anton R. Ivanov
Cambridgegreys Limite
en_file(filename, of_read(OPENFLAGS()), 0);
if (ffd < 0) {
printk(KERN_ERR "Error %d opening bpf file", -errno);
Acked-By: Anton Ivanov
--
Anton R. Ivanov
Cambridgegreys Limited. Registered in England. Company Number 10273661
https://www.cambridgegreys.com/
Signed-off-by: Anton Ivanov
---
net/core/xdp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/xdp.c b/net/core/xdp.c
index d7bf62ffbb5e..20781ad5f9c3 100644
--- a/net/core/xdp.c
+++ b/net/core/xdp.c
@@ -386,7 +386,7 @@ EXPORT_SYMBOL_GPL(xdp_rxq_info_reg_mem_model
Signed-off-by: Anton Ivanov
---
samples/bpf/xdpsock_user.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/samples/bpf/xdpsock_user.c b/samples/bpf/xdpsock_user.c
index d08ee1ab7bb4..eb78159376eb 100644
--- a/samples/bpf/xdpsock_user.c
+++ b/samples/bpf/xdpsock_user.c
On 02/07/2019 15:40, Richard Weinberger wrote:
CC'ing um folks.
On Tue, Jul 2, 2019 at 3:01 PM Алексей wrote:
Hello, the parameter ETH_MAX_PACKET limited to 1500 bytes is the not
support jumbo frames.
This patch change ETH_MAX_PACKET the 65535 bytes to jumbo frame support
with user mode lin
On 12/07/2019 10:22, Anton Ivanov wrote:
On 02/07/2019 15:40, Richard Weinberger wrote:
CC'ing um folks.
On Tue, Jul 2, 2019 at 3:01 PM Алексей wrote:
Hello, the parameter ETH_MAX_PACKET limited to 1500 bytes is the not
support jumbo frames.
This patch change ETH_MAX_PACKET the
On 02/07/2019 15:40, Richard Weinberger wrote:
CC'ing um folks.
On Tue, Jul 2, 2019 at 3:01 PM Алексей wrote:
Hello, the parameter ETH_MAX_PACKET limited to 1500 bytes is the not
support jumbo frames.
This patch change ETH_MAX_PACKET the 65535 bytes to jumbo frame support
with user mode
Let's reset this one.
I cannot say I am happy with the current number of caveats on using
this. We should at least throw a small page similar to the one dedicated
to tpacket_v2 into the kernel docs (or amend the offload docs). As I do
not know all the corner cases well enough I find it difficu
[snip]
>> There is no requirement to bind to ETH_P_IP either and most code examples
>> going back more than 10 years to the days of TCP Illustrated use ALL.
> For send only sockets, it is often advised to pass 0 as protocol to
> socket(), so as to avoid having to spend cycles on packet reception
>
On 10/12/17 18:25, Willem de Bruijn wrote:
On Thu, Oct 12, 2017 at 12:30 PM, Willem de Bruijn
wrote:
On Thu, Oct 12, 2017 at 11:44 AM, Anton Ivanov
wrote:
Found it.
Two bugs canceling each other.
The bind sequence in: psock_txring_vnet.c is wrong.
It does the following addr.sll_protocol
/12/17 16:44, Anton Ivanov wrote:
Found it.
Two bugs canceling each other.
The bind sequence in: psock_txring_vnet.c is wrong.
It does the following addr.sll_protocol = htons(ETH_P_IP);
before calling bind.
If you set addr.sll_protocol to ETH_P_ALL where it should have been in
the first place
other test cases like setting it to ETH_P_IP and
giving it IPv6 traffic or the opposite, but my guess is that these will
fail too if they need GSO to be applied.
A.
On 10/12/17 15:12, Anton Ivanov wrote:
On 10/12/17 14:39, Willem de Bruijn wrote:
If I produce a real vnet frame out of a l
On 10/12/17 14:39, Willem de Bruijn wrote:
If I produce a real vnet frame out of a live kernel frame using
virtio_net_hdr_from_skb() and try to send it it fails on the check in
af_packet, while succeeding for tap. If I remove the af_packet check the
frame is accepted by the hardware too.
If I
mantics as my code so I have something to compare to.
A.
On 10/12/17 07:11, Anton Ivanov wrote:
On 12/10/17 01:19, Willem de Bruijn wrote:
On Wed, Oct 11, 2017 at 6:01 PM, Anton Ivanov
wrote:
[snip]
This will be tomorrow though, it is late here.
The only obvious difference I can see at thi
On 12/10/17 01:19, Willem de Bruijn wrote:
> On Wed, Oct 11, 2017 at 6:01 PM, Anton Ivanov
> wrote:
>> [snip]
>>
>>> This will be tomorrow though, it is late here.
>>>
>>> The only obvious difference I can see at this point is that I am using
>>&
[snip]
> This will be tomorrow though, it is late here.
>
> The only obvious difference I can see at this point is that I am using
> iovs and sending the vnet header as iov[0] and the data in pieces after
> that while your code is doing a send() for the whole frame. This should
> not make any diff
[snip]
> The test can be run both with and without ring:
>
> psock_txring_vnet -l 8000 -s $src_ip -d $dst_ip -v
> psock_txring_vnet -l 8000 -s $src_ip -d $dst_ip -v -N
>
> both with and without qdisc bypass ('-q').
Thanks, apologies, I was being inpatient. Started reading the source,
saw the
On 11/10/17 19:57, Willem de Bruijn wrote:
> On Wed, Oct 11, 2017 at 2:39 PM, Anton Ivanov
> wrote:
>> The check as now insists that the actual driver supports GSO_ROBUST, because
>> we have marked the skb dodgy.
>>
>> The specific bit which does this check is in
; -exec grep -H
GSO_ROBUST {} \;
That returns nothing in 4.x
IMHO - af_packet allocates the skb, does all checks (and extra may be
added) on the gso, why is this set dodgy in the first place?
A.
On 11/10/17 17:26, Willem de Bruijn wrote:
On Wed, Oct 11, 2017 at 11:54 AM, Anton Ivanov
wrote:
I
:
On Wed, Oct 11, 2017 at 11:54 AM, Anton Ivanov
wrote:
It is that patch.
I rolled it back and immediately got it to work correctly on a Broadcom
Tigon. I can test on all other scenarios, I have tried, I suspect it will
come back alive on all of them.
I am going to try to trace it through and see
no issues in accepting.
A.
On 10/11/17 14:50, Anton Ivanov wrote:
On 10/11/17 14:39, Willem de Bruijn wrote:
On Wed, Oct 11, 2017 at 4:39 AM, Anton Ivanov
wrote:
Hi all,
I am having an issue with af_packet.c
It fails to transmit any TSO frame submitted via raw socket + vnet
headers.
An
On 10/11/17 14:39, Willem de Bruijn wrote:
On Wed, Oct 11, 2017 at 4:39 AM, Anton Ivanov
wrote:
Hi all,
I am having an issue with af_packet.c
It fails to transmit any TSO frame submitted via raw socket + vnet headers.
An identical frame is considered valid for tap.
This may be due to
Hi all,
I am having an issue with af_packet.c
It fails to transmit any TSO frame submitted via raw socket + vnet
headers. An identical frame is considered valid for tap.
The frames are generated out of legit linux skbufs (in UML) and vnet
headers work for checksumming on raw, so I should hav
On 11/05/17 03:43, Jason Wang wrote:
>
>
> On 2017年05月10日 17:42, Anton Ivanov wrote:
>> On 10/05/17 09:56, Jason Wang wrote:
>>>
>>>
>>> On 2017年05月10日 13:28, Anton Ivanov wrote:
>>>> On 10/05/17 03:18, Jason Wang wrote:
>>>>>
On 10/05/17 09:56, Jason Wang wrote:
On 2017年05月10日 13:28, Anton Ivanov wrote:
On 10/05/17 03:18, Jason Wang wrote:
On 2017年05月09日 23:11, Stefan Hajnoczi wrote:
On Tue, May 09, 2017 at 08:46:46AM +0100, Anton Ivanov wrote:
I have figured it out. Two issues.
1) skb->xmit_more is har
[snip]
> Virtio-net net does not support BQL. Before commit ea7735d97ba9
> ("virtio-net: move free_old_xmit_skbs"), it's even impossible to
> support that since we don't have tx interrupt for each packet. I
> haven't measured the impact of xmit_more, maybe I was wrong but I
> think it may help in
On 10/05/17 03:18, Jason Wang wrote:
>
>
> On 2017年05月09日 23:11, Stefan Hajnoczi wrote:
>> On Tue, May 09, 2017 at 08:46:46AM +0100, Anton Ivanov wrote:
>>> I have figured it out. Two issues.
>>>
>>> 1) skb->xmit_more is hardly ever set under virtua
qdisc" + "always xmit_more
allowed"
A.
P.S. Cc-ing virtio maintainer
A.
On 08/05/17 08:15, Anton Ivanov wrote:
Hi all,
I was revising some of my old work for UML to prepare it for
submission and I noticed that skb->xmit_more does not seem to be set
any mor
Hi all,
I was revising some of my old work for UML to prepare it for submission
and I noticed that skb->xmit_more does not seem to be set any more.
I traced the issue as far as net/sched/sched_generic.c
try_bulk_dequeue_skb() is never invoked (the drivers I am working on are
dql enabled so t
29 matches
Mail list logo
