Karl
I have done the memset. Thanks. I think that for testing (and not for 
production) do

insmod ./pf_ring.ko enable_debug=1

and see in the syslog what message you see when bind fails.

Thanks Luca


On Jun 22, 2011, at 5:38 PM, Henderson, Karl wrote:

> Hi Luca,
> 
> I'm not sure if this will help, but it's the call to bind:
> 
>  rc = bind(ring->fd, (struct sockaddr *)&sa, sizeof(sa));
> 
> Line 324 in pfring_mod.c.
> 
> The call to bind is setting errno to 22.
> 
> The ring->fd value was 3.
> 
> I did notice that you're not doing a bzero on the sa structure, but this
> didn't seem to help.
> 
> BTW, I did an svn update this morning so I should have all the latest.
> 
> Thanks,
> Karl
> 
> On 6/21/11 4:35 PM, "Henderson, Karl" <[email protected]> wrote:
> 
>> The interface should be pci3p1 not pci3pi and Intel 82599EB Card
>> 
>> On 6/21/11 4:13 PM, "Henderson, Karl" <[email protected]> wrote:
>> 
>>> - pci3pi is an optical 10G Intel interface
>>> - Intell
>>> - https://svn.ntop.org/svn/ntop/trunk/PF_RING - (from .svn entries) I got
>>> this about a week ago
>>> - [root@hydradevva-nr1 ~]# ethtool -S pci3p1
>>> NIC statistics:
>>>    rx_packets: 10
>>>    tx_packets: 17
>>>    rx_bytes: 828
>>>    tx_bytes: 1314
>>>    rx_errors: 0
>>>    tx_errors: 0
>>>    rx_dropped: 0
>>>    tx_dropped: 0
>>>    multicast: 0
>>>    collisions: 0
>>>    rx_over_errors: 0
>>>    rx_crc_errors: 0
>>>    rx_frame_errors: 0
>>>    rx_fifo_errors: 0
>>>    rx_missed_errors: 0
>>>    tx_aborted_errors: 0
>>>    tx_carrier_errors: 0
>>>    tx_fifo_errors: 0
>>>    tx_heartbeat_errors: 0
>>>    rx_pkts_nic: 5
>>>    tx_pkts_nic: 17
>>>    rx_bytes_nic: 434
>>>    tx_bytes_nic: 1418
>>>    lsc_int: 6
>>>    tx_busy: 0
>>>    non_eop_descs: 0
>>>    broadcast: 1
>>>    rx_no_buffer_count: 0
>>>    tx_timeout_count: 0
>>>    tx_restart_queue: 0
>>>    rx_long_length_errors: 0
>>>    rx_short_length_errors: 0
>>>    tx_flow_control_xon: 0
>>>    rx_flow_control_xon: 0
>>>    tx_flow_control_xoff: 0
>>>    rx_flow_control_xoff: 0
>>>    rx_csum_offload_errors: 0
>>>    low_latency_interrupt: 0
>>>    alloc_rx_page_failed: 0
>>>    alloc_rx_buff_failed: 0
>>>    lro_aggregated: 0
>>>    lro_flushed: 0
>>>    lro_recycled: 0
>>>    rx_no_dma_resources: 0
>>>    hw_rsc_aggregated: 0
>>>    hw_rsc_flushed: 0
>>>    rx_flm: 0
>>>    fdir_match: 0
>>>    fdir_miss: 3
>>>    fdir_overflow: 0
>>>    fcoe_bad_fccrc: 0
>>>    fcoe_last_errors: 0
>>>    rx_fcoe_dropped: 0
>>>    rx_fcoe_packets: 0
>>>    rx_fcoe_dwords: 0
>>>    tx_fcoe_packets: 0
>>>    tx_fcoe_dwords: 0
>>>    tx_queue_0_packets: 7
>>>    tx_queue_0_bytes: 510
>>>    tx_queue_1_packets: 0
>>>    tx_queue_1_bytes: 0
>>>    tx_queue_2_packets: 6
>>>    tx_queue_2_bytes: 468
>>>    tx_queue_3_packets: 0
>>>    tx_queue_3_bytes: 0
>>>    tx_queue_4_packets: 0
>>>    tx_queue_4_bytes: 0
>>>    tx_queue_5_packets: 0
>>>    tx_queue_5_bytes: 0
>>>    tx_queue_6_packets: 4
>>>    tx_queue_6_bytes: 336
>>>    tx_queue_7_packets: 0
>>>    tx_queue_7_bytes: 0
>>>    tx_queue_8_packets: 0
>>>    tx_queue_8_bytes: 0
>>>    tx_queue_9_packets: 0
>>>    tx_queue_9_bytes: 0
>>>    tx_queue_10_packets: 0
>>>    tx_queue_10_bytes: 0
>>>    tx_queue_11_packets: 0
>>>    tx_queue_11_bytes: 0
>>>    tx_queue_12_packets: 0
>>>    tx_queue_12_bytes: 0
>>>    tx_queue_13_packets: 0
>>>    tx_queue_13_bytes: 0
>>>    tx_queue_14_packets: 0
>>>    tx_queue_14_bytes: 0
>>>    tx_queue_15_packets: 0
>>>    tx_queue_15_bytes: 0
>>>    rx_queue_0_packets: 4
>>>    rx_queue_0_bytes: 240
>>>    rx_queue_1_packets: 0
>>>    rx_queue_1_bytes: 0
>>>    rx_queue_2_packets: 0
>>>    rx_queue_2_bytes: 0
>>>    rx_queue_3_packets: 0
>>>    rx_queue_3_bytes: 0
>>>    rx_queue_4_packets: 0
>>>    rx_queue_4_bytes: 0
>>>    rx_queue_5_packets: 0
>>>    rx_queue_5_bytes: 0
>>>    rx_queue_6_packets: 6
>>>    rx_queue_6_bytes: 588
>>>    rx_queue_7_packets: 0
>>>    rx_queue_7_bytes: 0
>>>    rx_queue_8_packets: 0
>>>    rx_queue_8_bytes: 0
>>>    rx_queue_9_packets: 0
>>>    rx_queue_9_bytes: 0
>>>    rx_queue_10_packets: 0
>>>    rx_queue_10_bytes: 0
>>>    rx_queue_11_packets: 0
>>>    rx_queue_11_bytes: 0
>>>    rx_queue_12_packets: 0
>>>    rx_queue_12_bytes: 0
>>>    rx_queue_13_packets: 0
>>>    rx_queue_13_bytes: 0
>>>    rx_queue_14_packets: 0
>>>    rx_queue_14_bytes: 0
>>>    rx_queue_15_packets: 0
>>>    rx_queue_15_bytes: 0
>>> - Haven't tried it on other interfaces but it's worked on this box a
>>> number of times. Currently, I'm all locked out
>>> - I'm using this with TNAPI, so yes
>>> 
>>> Thanks
>>> 
>>> 
>>> On 6/21/11 3:44 PM, "Luca Deri" <[email protected]> wrote:
>>> 
>>>> Karl
>>>> sorry to over flood you with questions...
>>>> 
>>>> - what is the pci3p1 interface?
>>>> - Is this the broadcom or or the Intel interface?
>>>> - Are you using PF_RING from SVN (I mean 4.7.0) ?
>>>> - Can you send me the output of "ethtool -S pci3p1" ?
>>>> - Do you have this issue also with other interface types?
>>>> - are you using the sock of the PF_RING-aware drivers?
>>>> 
>>>> Cheers Luca
>>>> 
>>>> On Jun 21, 2011, at 9:09 PM, Henderson, Karl wrote:
>>>> 
>>>>> When calling pfring_open_multichannel(), I sometimes get returned: 0
>>>>> and when I print out the reason, I get error no: 22 Invalid argument.
>>>>> This happens on an interface that's clearly up and its IP can be pinged
>>>>> from another box.
>>>>> 
>>>>> When it gets in this state, it seems to be stuck for quite some time.
>>>>> I
>>>>> try many different things like pointing to to other interfaces and then
>>>>> back, warm reboots, cold reboots, etc. and then miraculously  things
>>>>> sometimes start working again.
>>>>> 
>>>>> Here's my general procedure after reboot:
>>>>> 
>>>>> rmmod ixgbe.ko
>>>>> modprobe dca
>>>>> insmod ./ixgbe.ko IntMode=3
>>>>> tail /var/log/messages
>>>>> ifconfig pci3p1 up
>>>>> insmod pf_ring.ko transparent_mode=2 quick_mode=1
>>>>> tail /var/log/messages
>>>>> killall irqbalance
>>>>> ./set_irq_affinity.sh pci3p1
>>>>> ethtool -S pci3p1
>>>>> ./pfcount_multichannel -i pci3p1 -w 5000 -b 99 -l 200 -n 16
>>>>> 
>>>>> Everything looks great on install, but then I just get invalid
>>>>> argument
>>>>> when I call open on this pci3p1 interface.
>>>>> 
>>>>> This is running on:
>>>>>   € Dell R510
>>>>>   € OS: RHEL 6.0 (needed for 10G NIC driver)
>>>>>   € 2 x Intel E5620 2.4 GHz Quad Core CPU with Hyper-Threading
>>>>>   € 24 GB RAM (6 x 4GB DDR2 1333 MHz DIMs)
>>>>>   € PERC H700 Integrated RAID Controller, 1GB NV Cache
>>>>>   € Disks:
>>>>>           € 2 x 146 GB SAS disks mirrored for OS Volume
>>>>>           € 12 x 300 GB 15k RPM SAS disks in RAID10 for Storage[1]
>>>>>   € Dual Port Broadcom Corporation NetXtreme II BCM5716 Gigabit
>>>>> Ethernet
>>>>> (rev 20)
>>>>>   € Dual Port Intel Corporation 82599EB 10-Gigabit Network Connection
>>>>> (rev 01)
>>>>> 
>>>>> Any ideas why I may be having this frustrating and intermittent
>>>>> problem?
>>>>> 
>>>>> Thanks,
>>>>> Karl
>>>>> _______________________________________________
>>>>> Ntop-dev mailing list
>>>>> [email protected]
>>>>> http://listgateway.unipi.it/mailman/listinfo/ntop-dev
>>>> 
>>>> ---
>>>> Bildung ist kein Verbrechen
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Ntop-dev mailing list
>>>> [email protected]
>>>> http://listgateway.unipi.it/mailman/listinfo/ntop-dev
>>> 
>>> _______________________________________________
>>> Ntop-dev mailing list
>>> [email protected]
>>> http://listgateway.unipi.it/mailman/listinfo/ntop-dev
>> 
>> _______________________________________________
>> Ntop-dev mailing list
>> [email protected]
>> http://listgateway.unipi.it/mailman/listinfo/ntop-dev
> 
> _______________________________________________
> Ntop-dev mailing list
> [email protected]
> http://listgateway.unipi.it/mailman/listinfo/ntop-dev

---
If you can not measure it, you can not improve it - Lord Kelvin

_______________________________________________
Ntop-dev mailing list
[email protected]
http://listgateway.unipi.it/mailman/listinfo/ntop-dev

Reply via email to