[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 Thu, Oct 12, 2017 at 1:58 PM, Anton Ivanov
wrote:
>
>
> 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.
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
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 =htons(ETH_P_IP);
>> befo
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 =htons(ETH_P_IP);
> before calling bind.
>
> If you set addr.sll_protocol to ETH_P_ALL where i
Also confirmed using my UML patchset. This is inside the UML guest.
root@blinky:~# iperf -c 192.168.98.1
Client connecting to 192.168.98.1, TCP port 5001
TCP window size: 414 KByte (default)
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 the test program blows up with
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
> 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 produce it a synthetic frame + vnet
Hi Willem,
Thanks for all your help so far.
I modified your test program to do sendmmsg as an option in addition to
send. I will send you a github pull req with the changes later today.
This allows to send let's say n frames (let's say 64) in one syscall -
probably the highest TX rate you can
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
>>> iovs and sending the vnet header as iov[0] and the
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
>> iovs and sending the vnet header as iov[0] and the data in pieces after
>> that while your code is doing
[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 Wed, Oct 11, 2017 at 3:39 PM, Anton Ivanov
wrote:
> 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
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 net_gso_ok()
>>
>> Now, lets's see
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 net_gso_ok()
Now, lets's see how many Ethernet drivers set GSO_ROBUST.
find drivers/net/ethernet -type f -name "*.[c,h]" -exec grep -H
GSO_RO
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 net_gso_ok()
>
> Now, lets's see how many Ethernet drivers set GSO_ROBUST.
>
> find d
Working through it at the moment.
The validation logic is prohibiting what the hardware considers to be a
perfectly legit skb.
Once I narrow down the culprit I will come back with my findings.
Thanks for pointing me where to look by the way.
A.
On 10/11/17 17:26, Willem de Bruijn wrote:
On
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 thro
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 exactly where it drops a
skb which the card has no
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 valid
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 validation. As of commit 104ba78c9880 ("pac
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
24 matches
Mail list logo
